Re: [RFC] Second parent for reverts

From: Johan Herland <johan@herland.net>
Date: May 10, 2007, 18:06 UTC
Message-ID: <200705102006.08624.johan@herland.net>
In-Reply-To: <alpine.LFD.0.98.0705100927340.3986@woody.linux-foundation.org>

On Thursday 10 May 2007, Linus Torvalds wrote:

Show 26 quoted lines

> 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