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

[Johan Herland <johan@herland.net>]

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

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. Examples 
include:

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.

2. "Cherry-Pick": When cherry-picking a commit onto another branch, you 
should be able to tell git which commit you are cherry-picking 
(git-cherry-pick would of course do this automatically). This could 
enable git to make smarter decisions when merging the two branches: If 
the cherry-picked commit would cause a conflict with the original 
commit, git can either skip it (since it knows that one version of this 
patch is already present), or it can at least present the conflict to 
the user with some more context than what is available today. Not to 
mention how this information could be used by blame/annotate.

3. "Rebased-From": This one can be filled in automatically by 
git-rebase, but when I think about it, it may be too similar 
to "Cherry-Pick" to warrant a separate field.

4. "Rebased-To": When doing a rebase like the following:

   A---B---C---D---E       <--- branch

       (Hmm. C is broken. Rebase D and E onto B)

   A---B---C---D---E
        \
         \--D'--E'         <--- branch

   git-rebase could now add a dummy commit F* to E with "Rebased-To: 
{Commit ID of D'}", thus making:

   A---B---C---D---E---F*..
        \    ,............:  (yes, this is a poorly drawn meta-arrow)
         \   v
          \--D'--E'        <--- branch

   This would make it easier for git to do the Right Thing when someone 
following the old branch tries to pull after the rebase.

5. Heck, while we're at it, move "Signed-off-by" into the header fields, 
where git can make more use of it.

6. Finally, allow people to add custom header fields prefixed by "X-" 
(like in HTTP), and make it easy for them to extend git tools to use 
these custom fields in various ways. If some of them end up being 
really useful, we can import them into git (and lose the "X-" prefix).


Now, in order to let people specify these fields we probably want to 
make these fields names settable from the command line. It should also 
be possible to use a template when doing the commit message in an 
editor. Something like:
==========
Optional headers fields (fill in if applicable)
Cherry-Pick:   ________
Reverts:       ________
Signed-Off-By: ________

Your commit message goes here:
________________________________
==========

Of course, git would have to verify/sanitize these fields when input, so 
they probably need some type information associated with them.


Furthermore we might want to think about the possibility of allowing 
annotations to previous commits, in order to allow these fields to be 
set after the commit has happened, but that's a topic for a 
whole 'nother discussion.


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 --]