summaryrefslogtreecommitdiff
path: root/git-merge-recursive.py
AgeCommit message (Collapse)AuthorFilesLines
2005-12-21merge-recursive: conflicting rename case.Libravatar Junio C Hamano1-11/+27
This changes the way the case two branches rename the same path to different paths is handled. Earlier, the code removed the original path and added both destinations to the index at stage0. This commit changes it to leave the original path at stage1, and two destination paths at stage2 and stage3, respectively. [jc: I am not really sure if this makes much difference in the real life merge situations. What should happen when our branch renames A to B and M to N, while their branch renames A to M? That is, M remains in our tree as is.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-11merge-recursive: cleanup setIndexStagesLibravatar Junio C Hamano1-12/+5
Fredrik points out there is a useful wrapper runProgram() used everywhere that we can use to feed input into subprocess. Use it to catch errors from the subprocess; it is a good cleanup as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-11merge-recursive: leave unmerged entries in the index.Libravatar Junio C Hamano1-8/+46
This does two things. - When one branch renamed and the other branch did not, the resulting half-merged file in the working tree used to swap branches around and showed as if renaming side was "ours". This was confusing and inconsistent (even though the conflict markers were marked with branch names, it was not a good enough excuse). This changes the order of arguments to mergeFile in such a case to make sure we always see "our" change between <<< and ===, and "their" change between === and >>>. - When both branches renamed to the same path, and when one branch renamed and the other branch did not, we attempt mergeFile. When this automerge conflicted, we used to collapse the index. Now we use update-index --index-info to inject higher stage entries to leave the index in unmerged state for these two cases. What this still does _not_ do is to inject unmerged state into the index when the structural changes conflict. I have not thought things through what to do in each case yet, but the cases this commit cover are the most common ones, so this would be a good start. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01merge-recursive: adjust git-ls-tree use for the latest.Libravatar Junio C Hamano1-1/+1
You need to pass -t flag if you want to see tree objects in "git-ls-tree -r" output these days. This change broke the tree structure reading code in git-merge-recursive used to detect D/F conflicts. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-30merge-recursive: match the unmerged index entry behaviour with merge-resolveLibravatar Junio C Hamano1-2/+0
This minimally changes merge-recursive to match what happens when O->A, O->B, A!=B 3-way filelevel merge leaves conflicts to the new merge-resolve behaviour. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-20merge-recursive: Replace 'except:'Libravatar Fredrik Kuivinen1-2/+2
Plain except:s are evil as they will catch all kinds of exceptions including NameError and AttrubiteError. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19merge-recursive::removeFile: remove empty directoriesLibravatar Junio C Hamano1-0/+4
When the last file in a directory is removed as the result of a merge, try to rmdir the now-empty directory. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-15Give python a chance to find "backported" modulesLibravatar Johannes Schindelin1-2/+4
python 2.2.1 is perfectly capable of executing git-merge-recursive, provided that it finds heapq and sets. All you have to do is to steal heapq.py and sets.py from python 2.3 or newer, and drop them in your GIT_PYTHON_PATH. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11merge-recursive: Use '~' instead of '_' to separate file names from branch namesLibravatar Fredrik Kuivinen1-2/+2
Makes it less probable that we get a clash with an existing file, furthermore Cogito already uses '~' for this purpose. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11merge-recursive: Add copyright noticeLibravatar Fredrik Kuivinen1-0/+3
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11merge-recursive: Indent the output properlyLibravatar Fredrik Kuivinen1-61/+69
If we have multiple common ancestors and have to recursively merge them then the output will be much more readable with this commit. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-09merge-recursive: Fix support for branch names containing slashesLibravatar Fredrik Kuivinen1-0/+1
A branch name could have a slash in it. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-09merge-recursive: Fix limited output of rename messagesLibravatar Fredrik Kuivinen1-8/+4
The previous code did the right thing, but it did it by accident. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-07merge-recursive: Only print relevant rename messagesLibravatar Fredrik Kuivinen1-7/+15
It isn't really interesting to know about the renames that have already been committed to the branch you are working on. Furthermore, the 'git-apply --stat' at the end of git-(merge|pull) will tell us about any renames in the other branch. With this commit only renames which require a file-level merge will be printed. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10Deal with $(bindir) and friends with whitespaces.Libravatar Junio C Hamano1-1/+1
... using HPA's shellquote macro. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-02[PATCH] Teach the recursive merge strategy about renames.Libravatar Fredrik Kuivinen1-185/+601
It will now merge cases where a file was renamed in one branch and modified in the other branch cleanly. We also detect a couple of conflict cases now that wasn't detected before. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-25[PATCH] recursive-merge: Don't print a stack trace when read-tree fails.Libravatar Fredrik Kuivinen1-3/+9
If the working tree is dirty read-tree will fail, and we don't want an ugly stack trace in that case. Also make sure we don't print stack traces when we use 'die'. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-13git-merge-recursive: Trivial RE fixes.Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-13[PATCH] Use a temporary index file when we merge the common ancestors.Libravatar Fredrik Kuivinen1-5/+18
With this change we can get rid of a call to 'git-update-index --refresh'. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-13[PATCH] Adjust git-merge-recursive.py for the new tool names.Libravatar Fredrik Kuivinen1-4/+4
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-13[PATCH] Don't output 'Automatic merge failed, ...'Libravatar Fredrik Kuivinen1-1/+0
git-merge.sh does this for us. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-13[PATCH] Be more like the 'resolve' strategy.Libravatar Fredrik Kuivinen1-35/+33
If there are non-mergeable changes leave the head contents in the cache and update the working directory with the output from merge(1). In the add/add and delete/modify conflict cases leave unmerged cache entries in the index. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-13[PATCH] Rename the 'fredrik' merge strategy to 'recursive'.Libravatar Fredrik Kuivinen1-0/+429
Otherwise we would regret when Fredrik comes up with another merge algorithm with different pros-and-cons with the current one. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>