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

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

Johannes Sixt <j6t@kdbg.org> writes:

>> We could reduce the number from two to one by providing a new
>> git-am-status command which outputs one of "CHERRY-PICKING",
>> "REVERTING", or "" (or maybe it would also handle rebase and am).  We
>> could also generalize it to "git-prompt-helper" or something by moving
>> that entire bunch of if statements inside.  This would replace calls to
>> "git describe".
>>
>> But you probably have a better idea.
>
> Isn't it mere coincidence that the content of these two files looks
> like a non-packed ref? Wouldn't it be better to consider the two akin
> to MERGE_HEAD (which is not a ref because it records more than just a
> commit name)?

That is an excellent thought that seems to have escaped everybody
involved in the review.

These things do not behave like refs.  They do not want reflogs (and
even if they had, the log would not mean much), and if we want to
add more information on the cherry-pick and revert in progress, they
are the most natural place to do so.

Another thing that makes me vote for treating them just like
FETCH_HEAD, MERGE_HEAD and other ALL_CAPS files like COMMIT_MSG is
what should happen in a repository with more than one working trees.
You do not want to share what "CHERRY_PICK_HEAD" means across them
only because they happen to record an object name.

Thanks for a bit of sanity.