Re: git merge commits are non-deterministic? what changed?

From: Jeff King <peff@peff.net>
Date: Nov 9, 2012, 16:16 UTC
Message-ID: <20121109161647.GB19725@sigill.intra.peff.net>
In-Reply-To: <vpq390idb8v.fsf@grenoble-inp.fr>

On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:

Show 19 quoted lines

> Ulrich Spörlein <uqs@spoerlein.net> writes:
> 
> >> > 2. Why the hell is the commit hash dependent on the ordering of the
> >> > parent commits? IMHO it should sort the set of parents before
> >> > calculating the hash ...
> >> 
> >> What would be the sort key?
> >
> > Trivially, the hash of the parents itself. So you'd always get
> >
> > ...
> > parent 0000
> > parent 1111
> > parent aaaa
> > parent ffff
> 
> That would change the behavior of --first-parent. Or you'd need to
> compute the sha1 of the sorted list, but keep the unsorted one in the
> commit. Possible, but weird ;-).

Right. The reason that merge parents are stored in the order given on the command line is not random or because it was not considered. It encodes a valuable piece of information: did the user merge "foo" into "bar", or did they merge "bar" into "foo"?

So I think this discussion is going in the wrong direction; git should never sort the parents, because the order is meaningful. The original complaint was that a run of svn2git produced different results on two different git versions. The important question to me is: did svn2git feed the parents to git in the same order?

If it did, and git produced different results, then that is a serious bug.

If it did not, then the issue needs to be resolved in svn2git (which _may_ want to sort the parents that it feeds to git, but it would depend on whether the order it is currently presenting is meaningful).

-Peff