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>
I really wanted to try this out, instead of asking for an adjustment
to the 'git merge' driver and waiting. For now the new strategy is
called 'fredrik' and not in the list of default strategies to be tried.
The script wants Python 2.4 so this commit also adjusts Debian and RPM
build procecure files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano