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?
