Three-way merge with the index as one way
- From
Petr Baudis <pasky@suse.cz>
- Date
- Nov 3, 2005, 00:34 UTC
- Message-ID
- <20051103003423.GH1431@pasky.or.cz>
- In-Reply-To
- <7v8xwummtm.fsf@assigned-by-dhcp.cox.net>
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...
Show 5 quoted lines
> 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.