Re: [PATCH 0/5] make room for "special ref"
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Dec 18, 2023, 08:24 UTC
- Message-ID
- <ZYABwulbgbAwDewD@tanuki>
- In-Reply-To
- <132a3daf-23fa-4575-a77f-bdf0a96fb5d8@gmail.com>
On Sat, Dec 16, 2023 at 10:20:09AM +0000, Andy Koppe wrote:
Show 19 quoted lines
> 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