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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 9, 2015, 05:55 UTC
Message-ID: <xmqqmvz5x4cc.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1436399058.4542.26.camel@twopensource.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).