Junio C Hamano wrote:
> If you first update "git checkout" so that it will pay attention to
> a custom reflog-action exported by Porcelain scripts that may want
> to internally use it to flip branches (and without a custom one, it
> will still record "checkout: moving from A to B"), without exporting
> custom reflog-action from "rebase" and other Porcelain scripts, that
> would not affect any externally visible behaviour.
rebase already sets a custom reflog-action; in fact,
'set_reflog_action rebase' is executed after it sources sh-setup. I
have to go out of my way to deliberately unset it before every
checkout invocation to avoid breaking all the tests in t/status-help.
Most unnatural way to go about writing a series, if you ask me.
> Tests modified by b397ea4863a1 (status: show
> more info than "currently not on any branch", 2013-03-13) do change
> the original "# Not currently on any branch" to "detached at", but I
> do not think b397ea4863a1 _wanted_ to say where the $onto commit was
> during the rebase (or was it?), so if they have to change to
> "detached from", I do not think it is a problem at all. I think it
> is very sane to update these selected "detached at" to "detached
> from" as needed.
... and you have missed the point yet again.
I previously wrote:
> I'd just like to point out quickly that I first attempted to write 6/6
> without this patch. It is absolutely impossible, because the
> "detached HEAD from/to" messages no longer make any sense when
> checkout starts respecting GIT_REFLOG_ACTION. At that point, I'm was
> just monkeying around the trash-directory running describes to somehow
> try and make the expected output equal to the actual output. There
> was no method to the madness, and I was literally losing my mind.
Let me try and explain this once again: to determine "HEAD detached
from/to", wt-status must look for a previous "checkout: " message in
the reflog. Since a rebase no longer executes a checkout, the
"detached HEAD from" message no longer has anything to do with the
rebase itself; it is completely _random_ and _incidental_, based on
what checkout operation was executed last (eg. in a previous test).
To change the "detached HEAD to" messages to "detached HEAD from"
messages, I have to turn myself into a monkey that goes around running
describes on the test-directory. After enduring hours of this
mind-numbing job, the final result will be a terrible mess; tests can
no longer be added, removed, reordered, or even tweaked. Everything
depends on the exact ordering of the tests, and the incidental
checkout invocations they contain.
> That would be a sensible compromise
How is it a compromise? It is most uncompromising.
> because we do not want to see
> either "detached at" or "detached from" during "rebase" in the
> longer term. We would rather want to see the message start with
> something like
> # Rebasing X on top of Y (23 commits remaining to be replayed)
> which is under discussion in a separate thread lately. The change
> to expected output (i.e. "detached at" to "detached from") will have
> to be changed again in that separate topic.
Orthogonal. I want checkout-dash now, and I should not have to be
asked to do something as unrelated as redoing 'git status' output to
get what I want.
Since you have made it clear that you will defend every bit of b397ea
against all odds, and since I want checkout-dash now, we have to do
something. I have a proposal: I will smudge the first line of the
'git status' output, before comparing it to make tests pass. Never
mind that the line is incidental and Wrong; since I have no say in the
matter, I will just sidestep the issue. I don't use the long-form
'git status' anyway, and am never going to see this ugliness. We both
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html