Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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:
>> *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.
--
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