The only visible change is that git-blame doesn't understand
"--compability" anymore, but it does accept "--compatibility" instead,
which is already documented.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes some cases faster as we don't have to build the commit graph.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
