Hi!

Check kde overlay ;) we used signed commits here

Rich Freeman писал 2012-06-01 16:42:
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric <kentfredric@...> 
> wrote:
>>
>> Nope, at least not as far as I can tell, and I just implemented 
>> commit
>> signature verification >_>
>
> I've been trying to find an example of a signed commit, but can't 
> find
> one anywhere, so it is hard to tell what it is doing without going
> through the git source carefully.  If you have an example of a signed
> commit feel free to send it to me.
>
> Note that I am NOT interested in the output of any git operation 
> (such
> as git log --show-signature, git show, etc) - these are all processed
> and do not reveal what is actually going on.  I want a copy of the
> actual file containing the signature.  If the signature is embedded 
> in
> the commit then I want the file in the objects directory tree that
> contains the commit.  They're just compressed text files (though it 
> is
> a bit of a pain to decompress them).
>
>> 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 filesystem WON'T look the same after a rebase.
>
> quick example (operations done in this order):
>
> file in commit A in master:
> 1
> 2
> 3
> 4
> 5
>
> file in commit B in a branch off of master:
> 1
> 2a
> 3
> 4
> 5
>
> file in commit C in master:
> 1
> 2
> 3
> 4a
> 5
>
> if you merge master into the branch you'll end up with a new commit D
> whose parent is B that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> if instead you rebase master into the branch you'll end up with a new
> commit D whose parent is C that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> The history for the branch will no longer contain B.  If there were 
> 14
> commits B1..14 you'd end up with 14 commits D1.14 that each contain
> the line 4a.  None of them would use the same trees as B1..14, and
> they can't use the same signatures as a result, even if only the tree
> was signed.   As far as the new history was concerned, line 4a was
> there before the branch was started.
>
> At least, that is my understanding of rebasing.  Again, I'm a bit of 
> a
> git novice, but I never really grokked git until I saw a presentation
> that didn't start with commands, but instead started out with just
> walking through the actual structure of the repository.  Once you 
> grok
> the COW model I find it all clicks into place.
>
> Rich

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@...
mailto:alexxy@g.o
mailto:alexxy@...