git/git-merge-recursive.py, branch v1.2.2

merge-recursive: Make use of provided bases

2006-02-02T20:30:51Z

This makes some cases faster as we don't have to build the commit graph. Signed-off-by: Fredrik Kuivinen Signed-off-by: Junio C Hamano

merge-recursive: Improve the error message printed when merge(1) isn't found.

2006-01-29T23:00:42Z

Signed-off-by: Fredrik Kuivinen Signed-off-by: Junio C Hamano

merge-recursive: conflicting rename case.

2005-12-22T06:34:59Z

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

merge-recursive: cleanup setIndexStages

2005-12-11T09:55:52Z

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

merge-recursive: leave unmerged entries in the index.

2005-12-11T09:47:15Z

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

merge-recursive: adjust git-ls-tree use for the latest.

2005-12-02T05:39:41Z

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

merge-recursive: match the unmerged index entry behaviour with merge-resolve

2005-11-30T10:37:06Z

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

merge-recursive: Replace 'except:'

2005-11-20T18:47:16Z

Plain except:s are evil as they will catch all kinds of exceptions including NameError and AttrubiteError. Signed-off-by: Fredrik Kuivinen Signed-off-by: Junio C Hamano

merge-recursive::removeFile: remove empty directories

2005-11-20T03:57:54Z

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

Give python a chance to find "backported" modules

2005-11-16T06:10:59Z

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 Signed-off-by: Junio C Hamano