Re: [PATCH 4/7] sequencer: introduce functions to handle autostashes via refs
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jan 22, 2024, 19:54 UTC
- Message-ID
- <a7712d26-7c63-4c77-b339-126d05be6b0d@gmail.com>
- In-Reply-To
- <Za5IoEjs0q7cf354@tanuki>
On 22/01/2024 10:51, Patrick Steinhardt wrote:
Show 18 quoted lines
> On Fri, Jan 19, 2024 at 12:09:25PM -0800, Junio C Hamano wrote: >> Patrick Steinhardt <ps@pks.im> writes: >> The conversion (rather, the introduction to allow refs API to be >> used to access them) look correct, but offhand I do not know what >> the implication of leaving the file based interface would be. > > We have said in past discussions that the sequencer state should remain > self contained, and that requires us to keep the files-based interface. > Refactoring it would likely be a larger undertaking, as we have also > said that refs must either have pseudo-ref syntax or start with "refs/". > > The sequencer with its "rebase-merge/autostash" files doesn't conform to > either of those requirements, so we would also have to rename those > reflike files. I doubt that this is really worth it, so I would keep > those around as internal implementation details of how the sequencer > works. 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
Best Wishes
Phillip