Gentoo Archives: gentoo-dev

From: Alexey Shvetsov <alexxy@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 01 Jun 2012 12:49:49
In Reply to: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Rich Freeman

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@×××××.com> > 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@×××××.com mailto:alexxy@g.o mailto:alexxy@×××××××××××××.ru