From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 5/6] status: do not depend on flaky reflog messages
Date: Sat, 15 Jun 2013 02:58:33 -0700 [thread overview]
Message-ID: <7vobb7lmpi.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CALkWK0mCK_-bUapAvcrwtNgGnT1=x1d=+J9RO1GK6ssHWP2ztA@mail.gmail.com> (Ramkumar Ramachandra's message of "Sat, 15 Jun 2013 13:32:51 +0530")
Ramkumar Ramachandra <artagnon@gmail.com> 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.
next prev parent reply other threads:[~2013-06-15 9:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 13:32 [PATCH 0/6] Fix git checkout - with rebase Ramkumar Ramachandra
2013-06-13 13:32 ` [PATCH 1/6] t/checkout-last: checkout - doesn't work after rebase Ramkumar Ramachandra
2013-06-13 17:46 ` Junio C Hamano
2013-06-13 18:30 ` Ramkumar Ramachandra
2013-06-13 20:38 ` Junio C Hamano
2013-06-13 13:32 ` [PATCH 2/6] rebase: prepare to write reflog message for checkout Ramkumar Ramachandra
2013-06-13 17:51 ` Junio C Hamano
2013-06-13 18:05 ` Ramkumar Ramachandra
2013-06-13 13:32 ` [PATCH 3/6] rebase -i: " Ramkumar Ramachandra
2013-06-13 17:52 ` Junio C Hamano
2013-06-13 13:32 ` [PATCH 4/6] wt-status: remove unused field in grab_1st_switch_cbdata Ramkumar Ramachandra
2013-06-13 17:54 ` Junio C Hamano
2013-06-13 13:32 ` [PATCH 5/6] status: do not depend on flaky reflog messages Ramkumar Ramachandra
2013-06-13 18:07 ` Junio C Hamano
2013-06-13 18:15 ` Ramkumar Ramachandra
2013-06-13 18:48 ` Ramkumar Ramachandra
2013-06-13 21:02 ` Junio C Hamano
2013-06-14 6:27 ` Ramkumar Ramachandra
2013-06-14 13:52 ` Junio C Hamano
2013-06-14 14:01 ` Ramkumar Ramachandra
2013-06-14 14:52 ` Junio C Hamano
2013-06-14 15:08 ` Ramkumar Ramachandra
2013-06-14 16:31 ` Junio C Hamano
2013-06-14 21:36 ` Ramkumar Ramachandra
2013-06-14 22:16 ` Junio C Hamano
2013-06-14 22:36 ` Junio C Hamano
2013-06-14 23:07 ` Junio C Hamano
2013-06-15 8:02 ` Ramkumar Ramachandra
2013-06-15 9:58 ` Junio C Hamano [this message]
2013-06-15 12:13 ` Ramkumar Ramachandra
2013-06-15 8:44 ` Ramkumar Ramachandra
2013-06-15 9:51 ` Junio C Hamano
2013-06-15 12:08 ` Ramkumar Ramachandra
2013-06-16 5:57 ` Junio C Hamano
2013-06-16 6:07 ` Ramkumar Ramachandra
2013-06-15 10:26 ` Junio C Hamano
2013-06-13 13:32 ` [PATCH 6/6] checkout: respect GIT_REFLOG_ACTION Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vobb7lmpi.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).