Re: [RFC] Second parent for reverts

[Johan Herland <johan@herland.net>]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

On Thursday 10 May 2007, Linus Torvalds wrote:
> On Wed, 9 May 2007, Linus Torvalds wrote:
> > If you want a "related to that commit" field, it should be a
> > separate field in the commit object. But since it doesn't really
> > have any real *semantic* meaning to git itself, it shouldn't be in
> > the header. We could, for example, make it be in the free-form
> > section, and teach our graphical visualization tools to
> > automatically turn it into a hyperlink.
> >
> > .. which we already do.
>
> Btw, sorry for harping on this issue, but one of the really *great*
> things about putting things in the free-form section is a somewhat
> unanticipated huge advantage:
>
>  - we've had much better integration with non-git users than any
> other SCM I've ever seen!
>
> [...]
>
> So in general, putting things into the headers and having git
> semantic meaning should be discouraged. The "parents" thing is
> special, because the whole "history" thing is very deeply integrated
> in git, and obviously has to be (any SCM that does _not_ have
> parenthood information is totally broken *cough*CVS/SVN*cough*), but
> other than that we should actually strive to _avoid_ anything with
> deep git semantics.

Ok. I'm sold. I will take my header fields and go away before y'all 
replace me with a very small shell script. :)


BTW, I'm wondering whether anybody has ever thought about allowing 
after-the-fact annotations on commits. Kinda like free-form 
continuations on the commit message. It would allow people to make 
notes on previous commits that were either forgotten at commit-time, or 
only became apparent after the commit was done.

Furthermore, if we make git-blame pay attention to hints in the commit 
message (like Junio suggested somewhere else in this thread) - 
including the annotations - we can then add annotations to guide 
git-blame whenever it gets the blame wrong.

There's probably other things we could use this for.

Obviously we can't store the annotations in the commit object itself 
(because commit objects are immutable). I'm thinking annotations could 
be stored as simple (compressed) text files in .git/annotations/, under 
the same sha1/filename as the corresponding commit object is stored 
under .git/objects/. That would make them easy to retrieve from their 
corresponding commit.


Anyway, it's just an idea that struck me. Feel free to tell me why this 
is the worst idea since, oh, I don't know, say, my header fields 
idea...


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]