Re: Git commit generation numbers
- From
Jeff King <peff@peff.net>
- Date
- Jul 22, 2011, 22:02 UTC
- Message-ID
- <20110722220216.GA14118@sigill.intra.peff.net>
- In-Reply-To
- <CA+55aFzsZ6w_a_wPEuBjtDeSDYQviVfy9UmJMxPz4geu4CRthQ@mail.gmail.com>
On Fri, Jul 22, 2011 at 12:06:08PM -0700, Linus Torvalds wrote:
Show 9 quoted lines
> On Fri, Jul 22, 2011 at 11:34 AM, Jakub Narebski <jnareb@gmail.com> wrote: > > > > That is IF unknown headers are copied verbatim during rebase. For > > "encoding" header this is a good thing, for "generation" it isn't. > > Afaik, they aren't copied verbatim, and never have been. Afaik, the > only thing that has *ever* written commits is "commit_tree()" > (originally "main()" in commit-tree.c). Why is this red herring even > being discussed?
In git.git, that is the case. There are other programs that may write git commits, though. Try:
http://www.google.com/codesearch#search/&q=hash-object.*commit&type=cs
Many uses seem OK (they are generating a commit from scratch). This one at least (the sixth result from the search above) would actually generate buggy generation headers (it modifies parents but passes other headers through):
http://www.google.com/codesearch#XUVcT9DKB_U/replace&ct=rc&cd=7&q=hash-object.*commit
It may be worth saying that such code is stupid and ugly and wrong, or that it is not deployed widely enough to care about. But it's not entirely a red herring.
-Peff