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 ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
From: Jeff King <hidden> Date: 2016-06-15 22:55:13
On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
Ulrich Spörlein [off-list ref] writes:
quoted
quoted
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
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
On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote:
On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
quoted
Ulrich Spörlein [off-list ref] writes:
quoted
quoted
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
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).
Yeah, thanks, looks like I have some more work to do. I don't quite get
how it could come up with a different order, seeing that it is using svn
as the base.
Will run some more experiments, thanks for the info so far.
Cheers,
Uli
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:15
Ulrich Spörlein venit, vidit, dixit 09.11.2012 19:27:
On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote:
quoted
On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
quoted
Ulrich Spörlein [off-list ref] writes:
quoted
quoted
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
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).
Yeah, thanks, looks like I have some more work to do. I don't quite get
how it could come up with a different order, seeing that it is using svn
as the base.
Will run some more experiments, thanks for the info so far.
There was a change in the order in which "git cherry-pick A B C" applies
the commits. It's the only odering affecting change in 1.8.0 that I can
think of right now.
Michael
On Mon, 2012-11-12 at 12:27:31 +0100, Michael J Gruber wrote:
Ulrich Spörlein venit, vidit, dixit 09.11.2012 19:27:
quoted
On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote:
quoted
On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
quoted
Ulrich Spörlein [off-list ref] writes:
quoted
quoted
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
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).
Yeah, thanks, looks like I have some more work to do. I don't quite get
how it could come up with a different order, seeing that it is using svn
as the base.
Will run some more experiments, thanks for the info so far.
There was a change in the order in which "git cherry-pick A B C" applies
the commits. It's the only odering affecting change in 1.8.0 that I can
think of right now.
Just to wrap this up, it was of course a "feature" of the converter,
that resulted in this unrepeatable behavior. The SVN API makes use of
apr_hashes, which were traversed in arbitrary order, hence SVN commits
spanning multiple git-branches would be handled in a non-deterministic
order, leading to randomly ordered parent objects for later git merge
commits.
It it still debatable, whether a merge commit should have a
list-of-parents or a set-of-parents. Changing it to a set-of-parents
(with a well-defined hash function), would have made this problem go
away.
But this will never be changed, it would break the fundamental git
storage model as it is in place now.
Cheers,
Uli