Re: [PATCH] A new merge algorithm, take 2

From: Junio C Hamano <junkio@cox.net>
Date: Aug 28, 2005, 05:23 UTC
Message-ID: <7vmzn2prck.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050827205135.GB16587@c165.ib.student.liu.se>

Fredrik Kuivinen <freku045@student.liu.se> writes:

Show 8 quoted lines

> The main changes compared to the previous version are:
>
> * Lots of clean up.
> * Some of the scripts have been renamed to better match the naming
>   convention used in Git.
> * A new option ('-s') has been added to git-merge-cache
> * Unclean merges are detected and reported
> * Clean merges are committed

I have not looked deeply into your Graph thing, so I'd comment only on a couple of points in the external interfaces area.

I am not sure why you need to be touching merge-cache. I suspect that reading directly from "ls-files --stage -z" might be easier and certainly less intrusive. I do not have immediate objections to "read-tree -i", though. I think it is useful.

When there is a merge conflict, the current code leaves the index in unmerged state and intermediate merge result with conflict marker is left in the working tree. It appears that your code changes this and puts the blob with conflict markers in the index file. Leaving things in unmerged state has two advantages:

 - you _could_ run git-diff-stages to see what the changes in
   both sides are.

 - you cannot accidentally make a commit from such an index file
   state; in fact you cannot even write it out as a tree.

I understand why you do it this way, and I do not find your way _too_ problematic, but we do need to realize that this is making things somewhat more prone to human errors.

I have to admit that I find that "even when merging the merge-base candidates results in a file with conflict markers in it, the parts with the conflict markers often gets changed in the heads being merged, and the conflict markers will be gone from the result" trick very cute and interesting. By itself it has certain amusement value, and if it works well in practice that is great.

> +print 'Merging', h1, 'with', h2
> +h1 = runProgram(['git-rev-parse', '--revs-only', h1]).rstrip()
> +h2 = runProgram(['git-rev-parse', '--revs-only', h2]).rstrip()

Here, '--verify" would be the right flag to give to these.  Perhaps:

    h1 = runProgram(['git-rev-parse', '--verify', ('%s^0' % h1)]).rstrip()