Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@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:43:50
Message-Id: CAGfcS_nxsfnRsDWq=Nc-eE6KR0s5tsY9MdKsORPCfVUXCF1Kag@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Kent Fredric
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

Replies