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

From: Johannes Sixt <[email-masked]>
Date: Wed, 08 Jul 2015 23:14:55 +0200

Am 08.07.2015 um 21:16 schrieb David Turner:
> On Wed, 2015-07-08 at 19:46 +0200, Johannes Sixt wrote:
>> Am 08.07.2015 um 02:55 schrieb David Turner:
>>> Instead of directly writing to and reading from files in
>>> $GIT_DIR, use ref API to interact with CHERRY_PICK_HEAD
>>> and REVERT_HEAD.
>>>
>>> Signed-off-by: David Turner <[email-masked]>
>>> ---
>> ...
>>> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
>>> index 366f0bc..e2c5583 100644
>>> --- a/contrib/completion/git-prompt.sh
>>> +++ b/contrib/completion/git-prompt.sh
>>> @@ -415,9 +415,9 @@ __git_ps1 ()
>>>    			fi
>>>    		elif [ -f "$g/MERGE_HEAD" ]; then
>>>    			r="|MERGING"
>>> -		elif [ -f "$g/CHERRY_PICK_HEAD" ]; then
>>> +		elif git rev-parse --quiet --verify "CHERRY_PICK_HEAD" >/dev/null; then
>>>    			r="|CHERRY-PICKING"
>>> -		elif [ -f "$g/REVERT_HEAD" ]; then
>>> +		elif git rev-parse --quiet --verify "REVERT_HEAD" >/dev/null; then
>>>    			r="|REVERTING"
>>>    		elif [ -f "$g/BISECT_LOG" ]; then
>>>    			r="|BISECTING"
>>
>> We are trying very hard not to spawn any new processes in __git_ps1().
>> So, I raise a moderate veto against this hunk.
>
> Do you have an alternate suggestion about how to accomplish the same
> thing? Here are my ideas:
>
> We could special-case CHERRY_PICK_HEAD and REVERT_HEAD to be files
> independent of the ref backend, but that tends to complicate the
> backends.  I think this is a mistake.
>
> 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)?

-- Hannes