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

> Junio C Hamano <gitster@pobox.com> 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?
>