From: Taylor Blau <me@ttaylorr.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, hanwenn@gmail.com
Subject: Re: [PATCH 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb
Date: Wed, 29 Nov 2023 16:45:00 -0500 [thread overview]
Message-ID: <ZWew3CP4QJ4XDnHj@nand.local> (raw)
In-Reply-To: <35b74eb972eed7e08190e826fabcf6b7a241f285.1701243201.git.ps@pks.im>
On Wed, Nov 29, 2023 at 09:14:12AM +0100, Patrick Steinhardt wrote:
> We read both the HEAD and ORIG_HEAD references directly from the
> filesystem in order to figure out whether we're currently splitting a
> commit. If both of the following are true:
>
> - HEAD points to the same object as "rebase-merge/amend".
>
> - ORIG_HEAD points to the same object as "rebase-merge/orig-head".
>
> Then we are currently splitting commits.
>
> The current code only works by chance because we only have a single
> reference backend implementation. Refactor it to instead read both refs
> via the refdb layer so that we'll also be compatible with alternate
> reference backends.
>
> Note that we pass `RESOLVE_REF_NO_RECURSE` to `read_ref_full()`. This is
> because we didn't resolve symrefs before either, and in practice none of
> the refs in "rebase-merge/" would be symbolic. We thus don't want to
> resolve symrefs with the new code either to retain the old behaviour.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> wt-status.c | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 9f45bf6949..fe9e590b80 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1295,26 +1295,27 @@ static char *read_line_from_git_path(const char *filename)
> static int split_commit_in_progress(struct wt_status *s)
> {
> int split_in_progress = 0;
> - char *head, *orig_head, *rebase_amend, *rebase_orig_head;
> + struct object_id head_oid, orig_head_oid;
> + char *rebase_amend, *rebase_orig_head;
>
> if ((!s->amend && !s->nowarn && !s->workdir_dirty) ||
> !s->branch || strcmp(s->branch, "HEAD"))
> return 0;
>
> - head = read_line_from_git_path("HEAD");
> - orig_head = read_line_from_git_path("ORIG_HEAD");
> + if (read_ref_full("HEAD", RESOLVE_REF_NO_RECURSE, &head_oid, NULL) ||
> + read_ref_full("ORIG_HEAD", RESOLVE_REF_NO_RECURSE, &orig_head_oid, NULL))
Switching to read_ref_full() here is going to have some slightly
different behavior than just reading out the contents of
"$GIT_DIR/HEAD", but I think that it should be OK.
Before we would not have complained, if, for example, the contents of
"$GIT_DIR/HEAD" were malformed, but now we will. I think that's OK,
especially given that if that file is bogus, we'll have other problems
before we get here ;-).
Are there any other gotchas that we should be thinking about?
> + return 0;
> +
> rebase_amend = read_line_from_git_path("rebase-merge/amend");
> rebase_orig_head = read_line_from_git_path("rebase-merge/orig-head");
>
> - if (!head || !orig_head || !rebase_amend || !rebase_orig_head)
> + if (!rebase_amend || !rebase_orig_head)
> ; /* fall through, no split in progress */
> else if (!strcmp(rebase_amend, rebase_orig_head))
> - split_in_progress = !!strcmp(head, rebase_amend);
> - else if (strcmp(orig_head, rebase_orig_head))
> + split_in_progress = !!strcmp(oid_to_hex(&head_oid), rebase_amend);
> + else if (strcmp(oid_to_hex(&orig_head_oid), rebase_orig_head))
I did a double take at these strcmp(oid_to_hex(...)) calls, but I think
that they are the best that we can do given that we're still reading the
contents of "rebase-merge/amend" and "rebase-merge/orig-head" directly.
I suppose we could go the other way and turn their contents into
object_ids and then use oidcmp(), but it doesn't seem worth it IMHO.
Thanks,
Taylor
next prev parent reply other threads:[~2023-11-29 21:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 8:14 [PATCH 0/4] refs: improve handling of special refs Patrick Steinhardt
2023-11-29 8:14 ` [PATCH 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb Patrick Steinhardt
2023-11-29 21:45 ` Taylor Blau [this message]
2023-11-30 7:42 ` Patrick Steinhardt
2023-11-30 17:36 ` Taylor Blau
2023-11-29 8:14 ` [PATCH 2/4] refs: propagate errno when reading special refs fails Patrick Steinhardt
2023-11-29 21:51 ` Taylor Blau
2023-11-30 7:43 ` Patrick Steinhardt
2023-11-29 8:14 ` [PATCH 3/4] refs: complete list of special refs Patrick Steinhardt
2023-11-29 21:59 ` Taylor Blau
2023-11-30 7:44 ` Patrick Steinhardt
2023-11-30 15:42 ` Phillip Wood
2023-12-01 6:43 ` Patrick Steinhardt
2023-12-04 14:18 ` Phillip Wood
2023-11-29 8:14 ` [PATCH 4/4] bisect: consistently write BISECT_EXPECTED_REV via the refdb Patrick Steinhardt
2023-11-29 22:13 ` Taylor Blau
2023-11-29 22:14 ` [PATCH 0/4] refs: improve handling of special refs Taylor Blau
2023-11-30 7:46 ` Patrick Steinhardt
2023-11-30 17:35 ` Taylor Blau
2023-12-12 7:18 ` [PATCH v2 " Patrick Steinhardt
2023-12-12 7:18 ` [PATCH v2 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb Patrick Steinhardt
2023-12-12 20:24 ` Junio C Hamano
2023-12-12 23:32 ` Ramsay Jones
2023-12-13 0:36 ` Junio C Hamano
2023-12-13 7:38 ` Patrick Steinhardt
2023-12-13 15:15 ` Junio C Hamano
2023-12-14 9:04 ` Patrick Steinhardt
2023-12-14 16:41 ` Junio C Hamano
2023-12-14 13:21 ` Patrick Steinhardt
2023-12-12 7:18 ` [PATCH v2 2/4] refs: propagate errno when reading special refs fails Patrick Steinhardt
2023-12-12 20:28 ` Junio C Hamano
2023-12-13 7:28 ` Patrick Steinhardt
2023-12-12 7:18 ` [PATCH v2 3/4] refs: complete list of special refs Patrick Steinhardt
2023-12-12 7:19 ` [PATCH v2 4/4] bisect: consistently write BISECT_EXPECTED_REV via the refdb Patrick Steinhardt
2023-12-14 13:36 ` [PATCH v3 0/4] refs: improve handling of special refs Patrick Steinhardt
2023-12-14 13:36 ` [PATCH v3 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb Patrick Steinhardt
2023-12-14 13:37 ` [PATCH v3 2/4] refs: propagate errno when reading special refs fails Patrick Steinhardt
2023-12-14 13:37 ` [PATCH v3 3/4] refs: complete list of special refs Patrick Steinhardt
2023-12-14 13:37 ` [PATCH v3 4/4] bisect: consistently write BISECT_EXPECTED_REV via the refdb Patrick Steinhardt
2023-12-20 19:28 ` [PATCH v3 0/4] refs: improve handling of special refs Junio C Hamano
2023-12-21 10:08 ` Patrick Steinhardt
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=ZWew3CP4QJ4XDnHj@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=hanwenn@gmail.com \
--cc=ps@pks.im \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.