From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] wt-status: expand, not dwim, a "detached from" ref
Date: Wed, 13 May 2020 07:59:28 -0700 [thread overview]
Message-ID: <xmqq5zczx4mn.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <xmqqftc4wg96.fsf@gitster.c.googlers.com> (Junio C. Hamano's message of "Tue, 12 May 2020 22:33:41 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> OK. "Detached at <hash>" is somewhat unsatisfactory (you most
> likely have detached from refs/remotes/origin/<something>), but
> it is much better than "fatal" X-<.
>
>> One alternative is to plumb down a flag from dwim_ref() to
>> interpret_branch_mark() that indicates that (1) don't read HEAD when
>> processing, and (2) when encountering a ref of the form "<optional
>> ref>@{u}", don't die when the optional ref doesn't exist, is not a
>> branch, or does not have an upstream. (We cannot change the
>> functionality outright because other parts of Git rely on such a message
>> being printed.)
>
> Thanks for a good analysis. That likely is a good direction for a
> longer term. @{upstream} is "tell me the upstream of the branch
> that is currently checked out", right? So it is reasonable to
> expect that it has no good answer in a detached HEAD state. And
> when on a branch, that branch may not have an upstream, and we
> should prepare for such a case, too.
Well, I have to take this back.
The real cause of the problem is that we record in reflog that we
switched to @{u}, but when get_detached_from() tries to "dwim" it,
the "current branch" that is implicitly there to be applied to @{u}
is different one from what used to compute which branch to check
out, isn't it? And it probably is not limited to @{upstream} but
other @{<stuff>} that implicitly apply to the "current branch",
e.g. @{push}.
This causes a few potential problems:
- The "current" branch may be different from the one when such a
reflog entry that refers to @{<stuff>} when we later yank
@{<stuff>} out of the reflog and try to use it. This is the
problem the patch under discussion tries to hide, but the patch
also breaks cases that are working fine.
- Even if the user gave the branch name (i.e. 'next@{upstream}' in
the example this patch would have introduced a regression) or if
we updated get_detached_from() to correctly infer the branch that
was current when the reflog entry in which we found @{upstream}
was recorded, the upstream for the branch may have been
reconfigured between the time when the reflog entry was written
and get_detached_from() is called. 'next@{upstream}' may have
been 'origin/next' back then but it may be a different
remote-tracking branch now. This issue is not solved by the
patch---the issue is unfixable unless we log the changes to the
branch configuration so that we can figure out what was the
upstream of 'next' back then, which we won't do.
Assuming that is the root cause, I think the right solution likely
lies along these three lines:
(1) record not @{<stuff>} (or <branch>@{<stuff>} for that matter),
but the actual starting point in the reflog (e.g. in the
example this patch would have introduced a regression,
i.e. next@{u}, we should record 'origin/next'. In the example
this patch would have used degraded output to prevent dying,
i.e. @{u}, we should also record 'origin/next')---this also
will fix the "the branch's upstream may be different now"
problem.
(2) a patch like yours to use expand_ref() as a fallback, but only
for the "@{<stuff>}" notation that depends on what the "then
current" branch was---this is a mere band-aid, like the patch
under discussion is, but at least it would not regress the
cases that are "working". "The upstream may be different now"
problem is still there.
(3) when we have to interpret @{<stuff>} found in the reflog, go
back to see which branch was current, and compute @{<stuff>}
relative to that branch---this would "fix" more cases than (2)
would, but it won't fix "the upstream can change" problem, and
I think the trade-off is not all that great.
I think the combination of (1) and (2) is likely to be the best way
to go. (1) will remove the root cause, and (2) will allow us to
cope with reflog entries before (1) is applied.
next prev parent reply other threads:[~2020-05-13 14:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 0:40 [PATCH] wt-status: expand, not dwim, a "detached from" ref Jonathan Tan
2020-05-13 5:33 ` Junio C Hamano
2020-05-13 14:59 ` Junio C Hamano [this message]
2020-05-18 22:24 ` Jonathan Tan
2020-08-27 1:47 ` Jonathan Nieder
2020-08-27 2:10 ` Junio C Hamano
2020-08-29 1:02 ` [PATCH v2 0/2] Fix for git checkout @{u} (non-local) then git status Jonathan Tan
2020-08-29 1:02 ` [PATCH v2 1/2] sha1-name: replace unsigned int with option struct Jonathan Tan
2020-08-29 18:44 ` Junio C Hamano
2020-08-29 1:02 ` [PATCH v2 2/2] wt-status: tolerate dangling marks Jonathan Tan
2020-08-29 18:55 ` Junio C Hamano
2020-08-31 17:17 ` Jonathan Tan
2020-08-31 17:37 ` Junio C Hamano
2020-09-01 22:28 ` [PATCH v3 0/3] Fix for git checkout @{u} (non-local) then git status Jonathan Tan
2020-09-01 22:28 ` [PATCH v3 1/3] sha1-name: replace unsigned int with option struct Jonathan Tan
2020-09-01 22:28 ` [PATCH v3 2/3] refs: move dwim_ref() to header file Jonathan Tan
2020-09-01 22:28 ` [PATCH v3 3/3] wt-status: tolerate dangling marks Jonathan Tan
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5zczx4mn.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).