Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs

[Junio C Hamano <gitster@pobox.com>]

David Turner <dturner@twopensource.com> writes:

> I didn't see this until after I had sent my previous message.  I think
> the "multiple working trees" argument is strong enough that I will
> change the code (and tests). 

Not just code, but we probably should step back a bit and clearly
define what we are trying to achieve.  I _think_ what we want are:

 - Everything under refs/* and their associated logs would be handed
   off to the "pluggable ref backend" when one is in use.

 - All ref-like things with one-level ALL_CAPS names are per working
   tree.

   - They do not participate in "prunable?" reachability
     computation.
   - They (typically) do not want "logs".
   - Each may have extra information specific to it.
   - You can however read an object name off of them.

One possible and straight-forward implementation to achieve
"ref-like things with one-level ALL_CAPS names are per working tree"
is to declare that they will not be handed off to the backend, but
will always be implemented as files immediately under $GIT_DIR/.

But note that there is no fundamental reason we have to do it that
way; an alternative would be to allow backends to store these things
per working tree, but then the interface to drive backends need to
tell them which working tree we are working from.

Unlike branches, HEAD must be per working tree; the "pluggable ref
backend" needs to be able handle HEAD when you introduce it.  So
from that point of view, "multiple working tree" is *not* a valid
argument why they *have* to be implemented as files under $GIT_DIR/.
If you plan to let the pluggable ref backend to handle HEAD, you
must have a solution for per working tree ref-like things anyway.

As to J6t's "no excessive plumbing invocations", I think the right
approach is to have a single "git prompt--helper" command that does
what the current script does to compute $r.  "we want to keep
peeking into files under $GIT_DIR/" alone is not a valid enough
reason to constrain us (I am fine if the solution we find
appropriate for the 'multiple working trees' and other issues ends
up being "we solve it by having them as files in $GIT_DIR" for other
reasons, though).