It seems to be the only sane way to do it: when a two-head merge is
done, and the merge-base and one of the two branches agree, the
merge assumes that the other branch has something new.
If we start creating virtual commits from newer merge-bases, and go
back to older merge-bases, and then merge with newer commits again,
chances are that a patch is lost, _because_ the merge-base and the
head agree on it. Unlikely, yes, but it happened to me.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the coolest merge ever.
[jc: with two "Oops that's not it" fixes from Johannes and Alex,
and an obvious type mismatch fix.]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since there are no external calls left in merge-recur, we do not need
to set the environment variable GIT_INDEX_FILE all the time.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since merge-recur is in C, and uses libgit, it can call the relevant
functions directly, without writing the index file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To handle renames properly, we iterate through all file names of both
heads, the current one, and the one to be merged.
Only that there was a bug, where it was checked if the file name was present
in both heads, but the result of the check was never used. Instead, the
merge proceeded as if both heads contained that file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It would not make sense to parse a virtual commit, therefore set the
"parsed" flag to 1.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This could result in a nasty infinite loop, or in bogus names (it used
the strlen() of the newly allocated buffer instead of the original
buffer).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There were two TODOs to remove sha_eq() and to convert users of
struct stage_data to active_cache users, but this is not possible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This contains mainly three sorts of fixes:
- get rid of small wrapper functions
- reuse the diff_filespec structure when sha1, mode & path are needed
- Junio's pedantic updates
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is just an update for people being interested. Alex and me were
busy with that project for a few days now. While it has progressed nicely,
there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
For impatient people: yes, it passes all the tests, and yes, according
to the evil test Alex did, it is faster than the Python script.
But no, it is not yet finished. Biggest points are:
- there are still three external calls
- in the end, it should not be necessary to write the index more than once
(just before exiting)
- a lot of things can be refactored to make the code easier and shorter
BTW we cannot just plug in git-merge-tree yet, because git-merge-tree
does not handle renames at all.
This patch is meant for testing, and as such,
- it compile the program to git-merge-recur
- it adjusts the scripts and tests to use git-merge-recur instead of
git-merge-recursive
- it provides "TEST", a script to execute the tests regarding -recursive
- it inlines the changes to read-cache.c (read_cache_from(), discard_cache()
and refresh_cache_entry())
Brought to you by Alex Riesen and Dscho
Signed-off-by: Junio C Hamano <junkio@cox.net>
