Three-way merge with the index as one way

Dear diary, on Sun, Oct 16, 2005 at 12:34:29AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I suspect cg-Xlib::tree_timewarp, which currently does
> "git-read-tree -m $branch" followed by diff-tree piped to xargs,
> can be taught to use "git-read-tree -m -u $base $branch" (and
> lose the git-checkout-index -f -a immediately after that while
> we are at it), but I do not do Porcelain, so...

This is problematic, since with our current way of tree timewarping,
restoring local changes to files which got deleted will make patch error
out, etc.

I wanted to make tree_timewarp do three-way merge, but didn't figure a
good way to do it. First, what do I want - a two-way merge between two
trees, which will however respect (not die on) local changes in the
working tree.

One approach is to take the working tree, construct a tree object from
it and then run the regular three-way merge on that. But that is a waste
of time and pollutes the database with nonsensical objects. The
advantage is that I can reuse the per-file merge resolution script
without any changes.

However, this seems to be the only way to do this right now. What do you
think about the disadvantages - should we care? A possible alternative I
can imagine is to make a two-way merge mode which somehow records the
conflicts with index back in the index file instead of committing
suicide. Possibly the hex(-1) sha1 might be used for the relevant index
items, meaning "the current working copy". The per-file merge resolution
scripts would have to be tweaked for this then, but it shouldn't be that
hard; what I found hard was actually getting my head 'round the weird
git-read-tree code recording the stages in the index file. ;-)

Opinions?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html