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:
file in commit B in a branch off of master:
file in commit C in master:
if you merge master into the branch you'll end up with a new commit D
whose parent is B that looks like:
if instead you rebase master into the branch you'll end up with a new
commit D whose parent is C that looks like:
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.