Re: [PATCH 5/6] status: do not depend on flaky reflog messages

Ramkumar Ramachandra [off-list ref] writes:

2. The following no longer updates status:

  # in the middle of a rebase
  $ git reset @~2

The constant "HEAD detached at $onto" message is misleading and Bad.
Besides, wasn't this the primary usecase you wanted?

See the other message.  The first line from status in the middle of
a rebase is secondary.  End-user initiated "checkout" to detach is
the primary thing.

You previously wrote:

quoted

*1* One thing I could think of is to start sightseeing or (more
    realistically) manually bisecting at a given release point,
    reset the detached HEAD around several times, and then want to
    be reminded where the session started from.  I do not think it
    is particularly a very good example, though.

Whether the HEAD is detached by bisect or rebase is irrelevant.

You read and reacted to "bisect" too literally and missed
"manually".  The scenario I had in mind does _not_ use "git bisect"
command, which may _internally_ run "git checkout" to detach, but
for exactly the same reason why you want to touch "git rebase" in
this series, its use of "checkout" should not count for the next
"checkout -".

The sequence of "manually bisecting" is like

	$ git checkout v1.8.3
        ... test
        $ git status
        $ git log --oneline --first-parent v1.8.2..$detached_from
        ... pick a likely point
        $ git reset --hard $that_point
        ... go back to test further

which I actually do fairly often, as I tend to know more about the
likely place something may have been broken than a mechanical "split
the history into about the same number of commits" bisection.

3. The problem is not unique to rebase at all; yet you have
special-cased it.  If this isn't a band-aid, what is?

It is an illustration for approach (2) in the other message.

In the longer term, you would want richer status output for various
detached state, and that "how about this" patch shows where new code
to support other cases should be added.

Junio C Hamano wrote:

The first line from status in the middle of
a rebase is secondary.  End-user initiated "checkout" to detach is
the primary thing.

quoted

3. The problem is not unique to rebase at all; yet you have
special-cased it.  If this isn't a band-aid, what is?

It is an illustration for approach (2) in the other message.

In the longer term, you would want richer status output for various
detached state, and that "how about this" patch shows where new code
to support other cases should be added.

Fine.  If that is what you want, we'll have to special-case every
known script-in-progress to stop writing the usual "HEAD detached
from" message.  That'll leave out only the "end-user cases", where you
argue that the message is helpful.