On 15/12/2023 21:21, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> ... For example, FETCH_HEAD currently stores not >> just a single object name, but can and is used to store multiple >> object names, each with annotations to record where they came from. >> There indeed may be a need to introduce a new term to refer to such >> "special refs". > > The "may be" here vaguely hints another possibility. If we manage > to get rid of the "special refs", we do not even have to mention > "special refs", and more importantly, we do not need extra code to > deal with them. > > For FETCH_HEAD, for example, I wonder if an update along this line > is possible: > > * Teach "git fetch" to store what it writes to FETCH_HEAD to a > different file, under a distinctly different filename (e.g., > $GIT_DIR/fetched-tips). Demote FETCH_HEAD to a pseudoref, and > store the first object name in that "fetched-tips" file to it. > > * Teach "git pull" to learn what it used to learn from FETCH_HEAD > (i.e., list of fetched tips, each annotated with what ref at what > repository it came from and if it is to be merged) from the new > "fetched-tips" file. > > The "special" ness of FETCH_HEAD is really an implementation detail > of how "git pull" works and how the findings of "git fetch" are > communicated to "git pull". The general refs API should not have to > worry about it, and the refs backends should not have to worry about > storing more than just an object name (or if it is a symbolic ref, > the target refname). > > An end-user command like "git log ORIG_HEAD..FETCH_HEAD" would not > be affected by changes along the above line, because the current > FETCH_HEAD, when used as a revision, will work as if it stores the > single object name that is listed first in the file. > > 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. > > Hmm? > 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. ATB, Ramsay Jones
