On 1 June 2012 22:54, Rich Freeman <ri...@gentoo.org> wrote: > On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric <kentfred...@gmail.com> 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 ) -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
