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:
signature.asc
Description: PGP signature
