Hello Phillip, Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > > Hopefully such a rule would stop us adding pseudorefs that are really > private state like MERGE_AUTOSTASH. I think that is good in the long > term but isn't it is happening now with this patch without any warning > to users? This patch changes the behavior of parse_worktree_ref() which > the files backend uses to figure out the path it should use when reading > and writing a ref. > I do agree with the problem you're outlining here. Changing `is_pseudoref_syntax()` does indeed break things since its also used by `parse_worktree_ref()`. I first thought I could get around this by adding the required missing refs, but even that wouldn't work. Because BISECT_START has dual nature, it act as a ref and also as file storing a branch name as Patrick mentions in detail in his email [1]. Meaning if `is_pseudoref_syntax()` identifies it as a pseudoref, it could be wrong and printing it as such might not work. But we can't not match it because that is the current expectation. So there is no way to make `is_pseudoref_syntax()` stricter without breaking backward compatibility. While we do want to reach that goal, we have to go about in the other way around, that i.e. 1. Fix all pseudorefs to have the '_HEAD' suffix. 2. Move bisect files to '$GIT_DIR/bisect-state' (see [1] for more details). After this, we can safely make `is_pseudoref_syntax()` stricter. Given this, I think for the next version, I'll do the following changes: 1. keep `is_pseudoref_syntax()` as is. 2. introduce `is_pseudoref()` which calls `is_pseudoref_syntax()` and also checks the content of the file. 3. replace use of `is_pseudoref_syntax()` with `is_pseudoref()` in this patch series. [1]: https://public-inbox.org/git/20240119142705.139374-1-karthik.188@xxxxxxxxx/T/#m6e3790e30613fd68349708faaf5f4d9c704ba677
Attachment:
signature.asc
Description: PGP signature
