Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)

From: Johan Herland <johan@herland.net>
Date: May 4, 2007, 12:22 UTC
Message-ID: <200705041422.13975.johan@herland.net>
In-Reply-To: <20070504111057.GI4489@pasky.or.cz>

On Friday 04 May 2007, Petr Baudis wrote:

Show 24 quoted lines

> On Fri, May 04, 2007 at 09:21:29AM CEST, Johan Herland wrote:
> > On Friday 04 May 2007, Jakub Narebski wrote:
> > > Besides I think it would be better to teach blame to ignore reversion
> > > commits (for example based on first line of commit message) than to
> > > mess with the history.
> >
> > I'm starting to see a pattern where people would like to tell git about
> > more complicated relationships between commits, so that git can make
> > more intelligent decisions when doing merge, blame, pickaxe, etc.
> >
> > Adding these relationships as part of the commit message seems like a
> > really stupid idea because git suddenly has to make sense of something
> > it has never parsed before, thus making all future and former git
> > commit messages a potential target for pattern (mis)matching by git.
> > Also, we seem to forget that we already have the perfect place to put
> > such information: The header fields preceding the commit message.
> >
> > I therefore propose adding header field names to commit objects that
> > illustrate the relationships people want to tell git about.
>
>   So I've looked it up, and the Linus' writeup on this is at
>
> 	http://news.gmane.org/find-root.php?message_id=<Pine.LNX.4.64.060425075800
>0.3701@g5.osdl.org>

Thanks a lot for the link. I hadn't seen that writeup.

For the record: I'm only interested in adding "machine-readable" headers in 
cases where _both_ of the following holds:
1. The header has a _clear_ and _unambiguous_ _meaning_.
2. git can use the header in a well-defined manner to make informed and better 
decisions on how to behave.

In Linus' writeup, he's correct in that "prior" is too loosely defined. However, if we can meet Linus' requirements for clearness and semantics, I actually think the core idea is very good.

Show 23 quoted lines

> > 1. "Reverts": Mark a commit as reverting another commit. This could be
> > used by git-log to cancel out pairs of commits, resulting in a cleaner
> > view of history. It can help blame/annotate. There are probably other
> > tools that can benefit from this information also.
>
>   Actually I think git-log is the one tool which shouldn't cancel it
> out. The number of reverts likely won't be overwhelming and reverting is
> actually pretty important event - it says "this has been tried and we
> decided it's not the way", also can have social meanings etc. It is an
> important piece of history. And people still want to actually see the
> change and possibly revive it. BTW, imagine their confusion if the
> history looks like
>
> 	1abcd5 Feature X
> 	37efab Release 2.3.1
> 	724b9c Revert feature X
>
> and git log would cancel out 1abcd5 and 724b9c. Feature X is part of
> 2.3.1 but not in the log..?!
>
>   The point is that the reverting/reverted commit pairs don't affect
> your current content (except maybe in an highly abstract way), and this
> is why pickaxe and blame should skip it (by default).

Of course git-log shouldn't skip reverted commit pairs _by_default_. But if someone is interested in a cleaner view of history (e.g. when making a changelog or whatnot), a command-line option for turning on this behaviour might be useful. Or maybe we don't want git-log to be affected by "Reverts" at all. But if pickaxe and blame can make real use of this header, that's sufficient reason to add it, I think.

>   The question wrt. Linus' criteria is if "it has enough of a meaning",
> and I wonder about that too. I think it does, though.

As stated above, I don't want header fields unless they have clearly defined meaning and semantics. I doubt that all of my examples will fulfill these criteria, but some of them should, and that may be useful enough.

>   For the other suggested headers, it should be already mostly obvious
> from Linus' writeup why they shouldn't qualify, though.

I agree with Linus in that if we cannot define clear meaning and accompanying semantics, then adding a header is useless. I do, however, think that there are cases where we _can_ define the meaning and semantics, and in those cases, I do believe header fields to be a good idea.

As for "Cherry-Pick", it is of course not useful when the commit pointed to is not in the repo, but in the cases where it _is_, it might be very useful. It's a tradeoff, and we might end up deciding that "Cherry-Pick" is not worth it, but we should at least consider the possibility.

Have fun!

...Johan

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