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@xxxxxxxxxxx>
www.herland.net
Attachment:
signature.asc
Description: This is a digitally signed message part.