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

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