[Michael, sorry for the double mail -- I typoed the list address on
the first round.]
I recently looked into making merge-recursive more useful as a modular
piece in various tasks, e.g. Michael's git-imerge and the experiments
I made in showing evil merges.
This miniseries is the extremely low-hanging fruit. If it makes a
good first step for git-imerge, perhaps it can go in like this. It's
not a big speedup (about 2.2s vs 2.4s in a sample conflicting merge in
git.git), but it does feel much cleaner to avoid touching the worktree
unless actually necessary.
Otherwise it's probably not worth it just yet; for what I want to do
with it, we need some more reshuffling of things.
Thomas Rast (3):
merge-recursive: remove dead conditional in update_stages()
merge-recursive: untangle double meaning of o->call_depth
merge-recursive: -Xindex-only to leave worktree unchanged
Documentation/merge-strategies.txt | 4 ++++
merge-recursive.c | 46 +++++++++++++++++++++-----------------
merge-recursive.h | 1 +
t/t3030-merge-recursive.sh | 13 +++++++++++
4 files changed, 43 insertions(+), 21 deletions(-)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html