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

From: David Turner <[email-masked]>
Date: Wed, 08 Jul 2015 19:44:18 -0400

On Wed, 2015-07-08 at 16:23 -0700, Junio C Hamano wrote:
> Johannes Sixt <[email-masked]> 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.

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).