I recently ran into a situation where numerous changes were made to the same file on two separate branches, but only a few of these changes result in merge conflicts. However mercurial still requires me to manually merge the entire file for some reason.
A simplified scenario is illustrated in the screenshot:
Here we have a line being removed in the current branch, a line modified in both branches, and a line added in the other branch. Instead of prompting me to resolve just the merge conflict in the second line, I have to manually merge all 3 lines. There's got to be a better way right?
Using the mercurial internal merge tools gets me close to what I want, but it's definitely not scalable for larger files being merged in the real world.
1 Anchor
2 Anchor
3 <<<<<<< local
4 Line modified by other branch
5 =======
6 Line modified by this branch
7 >>>>>>> other
8 Anchor
9 Line added by other branch
10
Does anyone know how to configure any merge tool for mercurial that would pre-merge the non-conflicting lines?
Related
I apologize in advance it's kind of silly question. But I just can't wrap my head around it: why NOT EVERY change I make on my current branch will cause merging conflict? If line X in my version of a file on a local branch is NOT identical to the same line in the same file on a remote branch - why NOT necessarily it will end up with a conflict? It there something special about adding/deleting lines rather than CHANGING lines of code? Please find the screenshot attachedenter image description here
I'm in the process of doing a merge, and I'm ready to commit at this point but my commit dialog in TortoiseHg is showing many files as modified but when I diff to parents it says all files are binary equal.
I do not have and have never had the eol extension enabled.
Revert changes nothing, the file is still registering as modified.
hg parents shows two parents for the file.
hg stat shows the file as modified, e.g.
c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs
M Authorization\AuthorityGroups.cs
hg diff --git shows nothing, e.g.
c:\Projects\MyProject>hg diff --git Authorization\AuthorityGroups.cs
c:\Projects\MyProject>
I've tried this on two different machines on two separate clones and I'm seeing the same thing.
Any other thoughts for how I could diagnose or fix this?
Clearly something has changed but if it's not showing in hg diff --git how can I establish what that might be?
Update 2014/12/10:
I've done a bit more checking on the history of the two parent revisions and I think I see why it's getting confused.
We've got the original parent file added in revision 1 on default.
On the Apple branch the file has been renamed to move it to a new location.
On the Orange branch the file has been added to move it to the same new location.
So the file on both branches is binary identical and at the same location, but presumably Mercurial is flagging it as a difference to be merged because they arrived there by apparently different means.
So the question then becomes:
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history) , or do I just need to let it go through in the merge?
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history)
Well... sort of. Update to the most recent Orange commit in which the files had their old names (you can use hg bisect to find it if you're not sure exactly when it happened), do hg rename to the new names, commit, and then merge this into the current Orange head. Mercurial should be smart enough to register the files as properly renamed, and it won't cause conflicts (we know this because the more complex Apple/Orange merge didn't).
or do I just need to let it go through in the merge?
This is easier. Mercurial's merging algorithm is quite smart. It can deal with situations like this just fine.
Unless you have a third branch in which the files were never moved, the second option is unlikely to cause a problem. If you do have such a branch, you should be fine as long as you merge it into a descendant of the Apple rename (or merge from such a descendant). The major difficulty would be with merges to or from the Orange branch.
I have been fumbling around on github, and now with some help I have managed to make my branch the local master. however, I get these lines that i guess are tracking where things have been changed. But I don't want them!! I really just want my current files to become the new master as they are.
What exactly are these lines for? And how do I suppress them?
<<<<<<< HEAD
=======
>>>>>>> master
Those lines signal merge conflicts in Git.
When you do a merge, git is generally good at automatically working out how to merge files together, however there are some cases where it cannot - for example, when both branches are adding to the same kind of area in the same file, you get a merge conflict.
In these cases, those lines will be drawn around the boundary of the conflict. The section above the ======= belongs to the HEAD ref (or whatever is displayed after <<<<<<<). The section below belongs to the master ref (or whatever is displayed after >>>>>>>).
It's up to you to delete these lines and make the according edit to the code. If you only want to take what is on the HEAD ref in the final version of the code (post-merge), then you delete everything below the ====== line - and visa versa if you want to only take what is on the master branch. Of course, you can also take both versions of the code by just removing the markers.
You can see the git manual for more information.
I understand that CVS is obsolete system in out time but my company use it.
Problem is the next. As usual when developing starts we create branch from head and start work. Some times later we re-base branch with head and merge head with branch. It is ok. But every next typically operations are with problem. Many-many files are marked as changed, but in fact files hasn't any changes! . And these files aren't become white they red. It's a problem, because we need to review all of it to be sure that file modified.
To re-base branch with head we have do (using WinCVS):
1.Click Update.. on some branch;
2.Check Create missing directories;
3.Check Get the clean copy;
4.Check Update using last check in time;
5.Select Revision to update;
6.Select Merge type.
Any ideas why this can happen?
Thanks.
Tag the HEAD after each rebase, and next time you rebase, set the root tag to the last tag you made.
Like this:
Create BRANCH from HEAD, tag HEAD with BRANCH_ROOT_1
Do some work in HEAD
Merge HEAD into BRANCH with root branch BRANCH_ROOT_1, tag HEAD with BRANCH_ROOT_2
Do some more work in HEAD
Merge HEAD into BRANCH with root branch BRANCH_ROOT_2, tag HEAD with BRANCH_ROOT_3
...
GIT and (recently) SVN do this sort of thing automatically, but with CVS you need to do it manually after each merge. It's one of many reasons CVS is to be avoided like the plague.
I would suggest checking line endings (Win/Unix).
I have seen problems with all files marked as changed because of time zone problems. For example files checked out on a server using UTC, and copied over the network to a pc using CET. Or a change in daylight savings time caused such problems.
I have always used TortoiseCVS and it's Merge command, so I don't know much about WinCVS.
vimdiff helps in showing the diff of two files graphically and allows us to pick the changes from left to right/right to left.
The files I am dealing with are huge files and most of the differences vimdiff reports can be auto-merged except a few.As it takes lot of time to go diff by diff in vimdiff and take the action.
I would like to know if there is an option available in vimdiff that automerges the differences in left and right files as long as there is no ambiguity and leaving the conflicted resolutions similar to the tools svn merge and cvs merge tools does?
Its not possible to auto-merge the changes in two files unless we have a base copy where these two files branched and changes done separately. If an item is on one side and not on the other,it can't judge whether this item was newly added or an existing item was deleted. As there is a base copy exists while merging files in a repository, cvs merge,svn merge can auto-merge the changes.
If you use no version control, you can try diff and patch this way:
Before changing your file (say, file.txt), make a backup of the original version (file.orig).
When changed are made, make a patch-file: diff file.orig file.txt >patch.txt
Get a file which you want to merge changes to (say, file2.txt).
Use patch: patch file2.txt patch.txt
Changes will be merged, conflicted rows will be placed in a separate file.
Looks like vimdiff does not allow that. Man page says
"vimdiff - edit two or three versions of a file with Vim and show differences"
But you can have a look at Kdiff3 which lets you compare and merge.