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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thomas Rast <trast@xxxxxxxxxxx> writes:

> Dominique Quatravaux <domq@xxxxxxxxxx> 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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]