git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,  git@vger.kernel.org
Subject: Re: [PATCH 4/7] sequencer: introduce functions to handle autostashes via refs
Date: Mon, 22 Jan 2024 12:16:51 -0800	[thread overview]
Message-ID: <xmqqy1chrumk.fsf@gitster.g> (raw)
In-Reply-To: <a7712d26-7c63-4c77-b339-126d05be6b0d@gmail.com> (Phillip Wood's message of "Mon, 22 Jan 2024 19:54:58 +0000")

Phillip Wood <phillip.wood123@gmail.com> writes:

>> ... These refs are not supposed to be accessed by the user in the
>> first place, and we do not document their existence to the best of my
>> knowledge. Also, `git rev-parse rebase-merge/autostash` would fail.
>
> Exactly "rebase-merge/autostash" is a detail of the rebase
> implementation, it is not a ref that users should be using.
>
>> So overall I think it's fine to leave this internal sequencer state as
>> self-contained as it is.
>
> That's my feeling too

Good.  As long as "git rev-parse rebase-merge/autostash" fails, and
regardless of the ref backend in use, we always do "read one line from
the on-disk file and run get_oid_hex() on it", I would be happy with
that direction.

Thanks.

[Footnote]

 * We seem to overuse strbuf_read_file() even when we expect that
   the file is a single-liner.  We have read_line_from_git_path() in
   wt-status.c that only reads one line and we may want to split it
   into two: one that takes a filename and calls the other with
   git_path("%s", filename), and the other that takes a path for any
   on-disk file, reads a single line, and returns the string that
   was read, or something like that.  We might later want to update
   the "other" function so that it errors out if there are extra
   trailing lines (i.e. we expect it is a single-liner, but that
   expectation is violated---now what?).

  reply	other threads:[~2024-01-22 20:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 10:39 [PATCH 0/7] refs: convert special refs to become normal pseudo-refs Patrick Steinhardt
2024-01-19 10:39 ` [PATCH 1/7] sequencer: clean up pseudo refs with REF_NO_DEREF Patrick Steinhardt
2024-01-19 19:14   ` Junio C Hamano
2024-01-22 10:36     ` Patrick Steinhardt
2024-01-22 11:49   ` Karthik Nayak
2024-01-22 12:28     ` Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 2/7] sequencer: delete REBASE_HEAD in correct repo when picking commits Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 3/7] refs: convert AUTO_MERGE to become a normal pseudo-ref Patrick Steinhardt
2024-01-19 19:28   ` Junio C Hamano
2024-01-22 10:45     ` Patrick Steinhardt
2024-01-24  3:19       ` Elijah Newren
2024-01-22 12:02   ` Karthik Nayak
2024-01-19 10:40 ` [PATCH 4/7] sequencer: introduce functions to handle autostashes via refs Patrick Steinhardt
2024-01-19 20:09   ` Junio C Hamano
2024-01-22 10:51     ` Patrick Steinhardt
2024-01-22 19:54       ` Phillip Wood
2024-01-22 20:16         ` Junio C Hamano [this message]
2024-01-19 10:40 ` [PATCH 5/7] refs: convert MERGE_AUTOSTASH to become a normal pseudo-ref Patrick Steinhardt
2024-01-19 10:40 ` [PATCH 6/7] refs: redefine special refs Patrick Steinhardt
2024-01-19 20:28   ` Junio C Hamano
2024-01-19 10:40 ` [PATCH 7/7] Documentation: add "special refs" to the glossary Patrick Steinhardt
2024-01-23 16:27   ` Phillip Wood
2024-01-24  9:05     ` 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=xmqqy1chrumk.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@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 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).