Re: [PATCH 2/2] rebase -i: new option --name-rev

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 8, 2012, 19:08 UTC
Message-ID: <7vaa3qewqw.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87399jnyxh.fsf@thomas.inf.ethz.ch>

Thomas Rast <trast@inf.ethz.ch> writes:

Show 9 quoted lines

> Dominique Quatravaux <domq@google.com> writes:
>
>> If set, the second column of the rebase todo contains named revisions (obtained
>> with git name-rev) instead of short SHA1s.
>
> Hum.  I'm not sure yet if I find that very useful, since frequently the
> names will just be 'topic', 'topic~1', ...., 'topic~N' if you are
> rebasing a topic with N+1 commits not in master.  But you might, so who
> am I to judge.

I think the only use case where this might be useful is when you have totally undescriptive one-line description to your commits that they alone do not help distinguishing the commits being picked, e.g.

  pick 47a02ff add frotz
  pick d41489a fix frotz
  pick 00c8fd4 fix frotz more
  pick 090ea12 again fix frotz
  pick 74775a0 fix frotz one more time
  pick 6f7f3be at least now frotz compiles

As we treat the one-line subject merely as a human aid, I would probably do not mind if a workaround for such an issue were done to produce something like this instead:

  pick 47a02ff (1) add frotz
  pick d41489a (2) fix frotz
  pick 00c8fd4 (3) fix frotz more
  pick 090ea12 (4) again fix frotz
  pick 74775a0 (5) fix frotz one more time
  pick 6f7f3be (6) at least now frotz compiles

It is not a problem with the current rebase-i that detaches HEAD while working, but using object names like "topic~7" that is relative to something inherently fluid (i.e. a branch) makes me feel nervous as an end user from aesthetics point of view.