I am trying to understand merging of unrelated histories. Git 'merge' command has an option "--allow-unmatched histories" to merge unrelated histories. I am missing some clarity here. The root folder in GIT is called as 'project'. project contains many repositories. Each repo may have several branches.
Considering all this. I have two 'projects' (a, b). In project 'a', I have a repo called 'arepo'. 'arepo' have a branch 'abranch'. Similarly, there is project 'b'. project 'b' has a repo called 'brepo'. 'brepo' has a branch called 'bbranch'.
The following picture depicts the situation:-
In this situation can we merge "abranch" and "bbranch" using "allow-unrelated-histories" option of GIT Merge?
Thanks in advance.
From here it says:
--allow-unrelated-histories By default, git merge command refuses to merge histories that do not share a common ancestor. This option can
be used to override this safety when merging histories of two projects
that started their lives independently. As that is a very rare
occasion, no configuration variable to enable this by default exists
and will not be added.
So it would appear that it is possible to merge unrelated histories by using the --allow-unrelated-histories option.
Related
I have a problem with saving different config files in my Mercurial repository. For example, I have 2 branches - dev and testing. For each, I have my Jenkinsfile (configuration of Jenkins pipeline). It also could be any other configuration files (DB config, other systems configs) that are different between branches. Each time when I merge testing with dev I should merge the Jenkinsfile manually. How could I solve this problem? I wanna save the history of my config files and don't wanna have any problems with merging. Is there any approach to solve this routine problem?
This could do the trick:
When you hit the merge conflict (obviously, you will see conflict every time when merging these two branches with a config file with the same name but different content) you can perform a re-merge only for that config file while also using the --tool flag to tell the "merge machine" that we want to keep the local version of this file, by running:
hg resolve path/to/config/file --re-merge --tool ':local'
Or short version: hg res path/to/config/file --re-merge -t ':local'
Note: hg merge also has this --tool option but be careful using that because it would apply that merge-tool to every file that will be merged in that operation.
To know more about merge tools, run: hg help merge-tools
Mercurial a lot of time have concepts of custom merge tools and merge-patterns (see MergeTools.rc and MergePatterns.rc)
I.e. you can for your Jenkinsfile (even it haven't unique perrepository extension, give it) custom mergetool, which will do just hg merge --tool internal:local
how is it possible to commit all selected projects from Eclipse to one github repository(as imaged below)?
Currently when I commit my new project to github, a new repository will be created.And I'd like to avoid creating massive number of new repositories.
Thank you in advance!
p.s.I found other related topics for this question, but don't know what I should do exactly.
need your help please.
There shall be an Eclipse plugin that'll do your git job but I'll tell you a generic solution in case that plugin is not helpful. Well, all these selected projects are directories basically and if they're residing inside the same directory, let say <dir-1>, then you can add the remote repo path to <dir-1> using git remote add origin <git-path> and then add all your directories i.e. projects which will be part of the git repo. Best case would be to create separate branches for each of these projects and then merge those branches to master when they reach a logical state without any breaking changes. Now, in case, if all these directories are not residing inside <dir-1> then create a symbolic link inside <dir-1> to all those projects (possibly with same names) so that whenever the original directories are updated these directories are also changed respectively. Check more about symbolic links.
Setup:
I have a client with a TFVC source control repository. The root is a folder, not a branch. Scattered throughout the hiearchy are branches, sometimes 2, sometimes 3 levels deep. For using git-tfs to migrate the repository, I need the root to be a branch. However, when I try to convert the root folder to a branch, I get this error:
You cannot create a branch at $/myProject because a branch already exists at $/myProject/Releases/7.3/Metadata.
If $/myProject/Releases/7.3/Metadata is not a branch convert it back to a folder and retry the operation.
Question:
Is there any impact to me "de-branching" some of those branches, turning them into regular folders, so that I can make the root a branch and then use git-tfs to migrate it? Could I possibly lose some of the history? Would I be risking corrupting the source control repository or losing any data? I'm trying to be very careful with the client's source code and not risk losing any data.
Thanks!
Update:
My justification for thinking I need to convert the root to a branch:
* When created a simple test repository to try out the migration, and ran this command
git tfs list-remote-branches https://mysite.visualstudio.com/
I got this message
"No TFS branches were found!"
And on this github issue, it said I should switch to a branch, then I would see it and that worked. So I assumed the clone wouldn't work since it didn't show up in the list. Also, with the similarly structured test repo, when I ran git tfs list-remote-branches, I got:
TFS branches that could be cloned:
$/myproject1/Releases/7.1/Metadata [*]
$/myproject1/Releases/7.2/Metadata [*]
$/myproject1/Releases/7.3/Metadata [*]
$/myproject1/Trunk/Main [*]
Cloning root branches (marked by [*]) is recommended!
PS:if your branch is not listed here, perhaps you should convert its
containing folder into a branch in TFS: -> Open 'Source Control
Explorer' and for each folder corresponding to a branch, right click
on the folder and select 'Branching and Merging' > 'Convert to
branch'.
Based on that, I thought I had to convert it to a branch.
The next command I ran was
git-tfs clone https://mysite.visualstudio.com/ $/myproject1
I thought this gave me an error when the root was a folder, but it just gave me a warning when I reran it just now. The folder structure was something like
folder/folder/branch
folder/folder/folder/branch/folder
etc
warning: you are going to clone the whole repository or too high in
the repository path ! => If you want to manage branches with
git-tfs, clone one of this branch instead :
- $/myproject1/Releases/7.1/Metadata
- $/myproject1/Releases/7.2/Metadata
So it looks like the reponses are right. You can clone off the root without a problem. Thanks!
Don't convert your branch to a folder.
What does the following command tell you to clone?
git tfs list-remote-branches http://tfs:8080/tfs
A doc on the subject :
https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/manage_tfs_branches.md#find-the-tfs-branch-to-clone-optional
Edit: git-tfs is able to clone every folders in a TFVC Collection but if you want to clone the history with the branches, each folder should be converted as a branch.
I'v tried to merge a hotfix of my current deployed release branch into my develope branch.
Intellij found only the changes that were in the hotfix.
eclipse on the other hand found additionally some changes between the release and the develope and put them on the unstaged files.
Why is there a difference between the 2 IDEs? Do they use different git merge or diff? Do they choose different common ancestors?
Thank you!
No, IDEs don't have anything to do with GIT internal commands.
I think it was a mistake from your own side. I suppose you have two local repos for two IDEs, right?
May be you accidentally merged with different branch.
You said eclipse put some files to upstaged change, may be there's a conflict to that merge. Resolve it.
Is it possible to merge changes across projects in TFS 2012? If so, it doesn't seem obvious to me how. I find myself needing to do this because we created a new project when we really should have created a branch (or reorganized our branches).
You can use baseless merging from within the IDE (select merge) or using the TF command line utility. The following image shows a merge from team project Area 52 to team project Area 51, where no branch relationship exists. The IDE correctly identifies the merge as a baseless merge:
Caution is advised though and I recommend you read the section on baseless merging in the Branching Guide (http://vsarbranchingguide.codeplex.com/) first.
I did quick test and documented the findings here in a rough format: http://blogs.msdn.com/b/willy-peter_schaub/archive/2012/12/13/faq-branching-is-easy-but-can-i-merge-without-branching.aspx
Yes you can, you have a couple of options. If the code is distinct e.g. you have something like this.
$/TeamProject1/Main/Source/Solution1
$/TeamProject2/Main/Source/Solution2
And you want to branch solution 1 across to team project 2 then you can just use the "branch" functionality in the Visual Studio UI. Put the appropriate path in the "target" textbox and you should be good.
If you have the same code in 2 separate team projects then you will need to do a baseless merge. e.g.
$/TeamProject1/Main/Source/Solution1
$/TeamProject2/Main/Source/Solution1
Open up a Visual Studio command prompt and navigate to your TFS workspace, then use the following command
tf merge $/TeamProject1/Main/Source/Solution1 $/TeamProject2/Main/Source/Solution1 /baseless /recursive
This will merge the 2 versions of solution 1. Be aware though that you may get problems if files have been renamed or deleted. TFS will also probably treat each file as a merge conflict (unless the content is identical) and you will manually need to decide which files (Source or Target) to overwrite / merge.
Once the baseless merge has been checked in then a merge relationship will be created and any further merges will be able to be done from the IDE.