Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:15

Thomas Rast [off-list ref] writes:
Dominique Quatravaux [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help