From: Junio C Hamano Date: Thu, 09 Jun 2005 02:15:15 GMT Subject: Re: Handling merge conflicts a bit more gracefully.. Message-ID: <7vll5kxolo.fsf@assigned-by-dhcp.cox.net> In-Reply-To: >>>>> "LT" == Linus Torvalds writes: LT> I think that sounds reasonable. Is it not the case now? Well, except that $I may validly be an empty tree ;-), so not quite. In case it was not clear, where I am headed is this. I would like to rip out the two-tree "carry forward" implementation from read-tree, and replace it with: read_cache() -- current goes to stage0 read_tree(H) -- H goes to stage1 read_tree(M) -- M goes to stage3 for each path if it appears in stage0, copy it to stage2 else if it appears in stage1, copy it to stage2 threeway_merge() !! And then the resulting possibly unmerged cache can be resolved exactly the same way with merge-cache. The trouble I feel with the current "carry forward" code is that when it works it does sensible thing, but otherwise does not help the end user at all. With all the work going into making merge-one-file-script nicer today, I think leveraging three-way merge support for two-tree fast forward case would make a lot more sense than keeping the all-or-nothing carry forward code I recently added to it. When/if that happens, then the current fast-forward code would need to be changed from: read-tree -m $H $M && echo $M >.git/HEAD to read-tree -m $H $M && if unmerged paths in the resulting cache then merge-cache -o merge-one-file-script -a fi && echo $M >.git/HEAD and the user's local changes since H when fast forwarding to M would be handled with the same workflow as the three-way case. Hmm.