On 1 June 2012 22:54, Rich Freeman <firstname.lastname@example.org> wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfredric@...> wrote:
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
> I think it is the tree that is signed, but that changes too.
Nope, at least not as far as I can tell, and I just implemented commit
signature verification >_>
> Rebasing re-applies the same diff to the new head to give you a new
> set of commits. When you apply the same diff to a different parent
> you end up with a different tree, so the tree signature won't be the
> same either.
Not nessecarily. Given that :
a file with a given content has a fixed SHA
A tree is just a list of these SHA's , and that in turn is referenced
by SHA, so if 2 commits have identical file content, their 'tree' sha
will be the same ( in theory ).
So that means, if you perform a rebase, assuming the filesystem looks
the same as it did before the rebase, it will have the same SHA1 for
the tree, regardless of the process of how it got to be that way.
The only SHA that has to change is the 'parent',
( Demonstration here: https://gist.github.com/2851330 , note I have 2
commits with the same tree sha, and the tree sha only really refers to
one file 3 times as all the empty files have same sha )
But unfortunately, with a rebase, even if the trees don't change, if
the history order changes, the commits themselves have to change due
to the "parent" sha needing to change ( yes, I know commits are
immutable in reality, and they don't change, but are duplicated and
the duplicate is given the new sha , but the effect is still the same
, because those unreferenced commits will eventually get reaped )
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"