Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit

[Junio C Hamano <gitster@pobox.com>]

Chris Johnsen <chris_johnsen@pobox.com> writes:

> My confusion was that I took "usually a mistake" to refer to the case
> where the user meant to commit content changes but forgot to first
> stage any changed content. But your clarification shows that "usually
> a mistake" really means that making any empty commit, intentional or
> not, is (considered to be) a fundamental misuse of SCM machinery.

The empty commits in your example a few messages ago are used as "piss in
the snow" marking.  If you did not have tags (and commit notes), it may be
the only workaround to say "here is an interesting point", but even then
such a workaround can only be made while the commit is at the tip, and be
made useful only by forcing all the other commits on the branch be on top
of that "piss in the snow" commit, so it is a flawed workaround.

Suppose you have this history.

 ---A---B---C

You found that the point C is interesting in some way, so you mark it:

 ---A---B---C---P

But somebody else may have developed on top of C bypassing P

              D---E---F
             /
 ---A---B---C---P

What would you do in such a case?  You cannot leave P dangling, as that
would mean P will not participate in future rebases (and you do not want
to rebase P on top of F because C is the point that is interesting to you,
not F).  Do you merge F and P only to make P not dangling?  What does such
a merge mean?

Worse yet, if you stared from the original history with three commits, how
would you mark that B is interesting?

          P   D---E---F
         /   /
 ---A---B---C


The facility git and other SCM offer you to leave such mark (possibly
after the fact) is to use tags.

So in your particular "piss in the snow" usage, I would agree that such an
empty commit is a misuse.

I am not however claiming that all uses of an empty commit are fundamental
misuses here, though.  Somebody else may have other valid uses.