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

Ulrich Spörlein [off-list ref] writes:

Two questions:
1. Can we impose a stable ordering of the commits being recorded in a
merge commit? Listing parents in chronological order or something like
that.

The order is determined by the order the refs are given to git merge (or
git commit-tree when using the plumbing).

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?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

On Fri, 2012-11-09 at 16:04:31 +0100, Andreas Schwab wrote:

Ulrich Spörlein [off-list ref] writes:

quoted

Two questions:
1. Can we impose a stable ordering of the commits being recorded in a
merge commit? Listing parents in chronological order or something like
that.

The order is determined by the order the refs are given to git merge (or
git commit-tree when using the plumbing).

quoted

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

hth
Uli