Re: [PATCH 0/5] make room for "special ref"

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Sat, Dec 16, 2023 at 10:20:09AM +0000, Andy Koppe wrote:
> On 15/12/2023 22:44, Ramsay Jones wrote:
> > On 15/12/2023 21:21, Junio C Hamano wrote:
> 
> > > If somebody is reading FETCH_HEAD and acting on its contents (rather
> > > than merely consuming it as a ref of the first object), perhaps
> > > feeding it to "git fmt-merge-msg", they will be broken by such a
> > > change (indeed, our own "git pull" will be broken by the change to
> > > "git fetch", and the second bullet point above is about fixing the
> > > exact fallout from it), but I am not sure if that is a use case worth
> > > worrying about.
> > 
> > Yes, I was going to suggest exactly this, after Patrick pointed out
> > that there were only two 'special psuedo-refs' (I had a vague feeling
> > there were some more than that) FETCH_HEAD and MERGE_HEAD.
> 
> According to the pseudoref entry of gitglossary, CHERRY_PICK_HEAD also
> stores additional data (which would imply that REVERT_HEAD does too).
> Looking at CHERRY_PICK_HEAD during a pick though, I only see a single hash,
> even when picking multiple commits.

Both CHERRY_PICK_HEAD and REVERT_HEAD are only ever updated via the refs
API, so neither of them ever contains anything other than a normal ref.
I guess we should update the glossary accordingly.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]