From: Johannes Sixt <j6t@kdbg.org>
To: David Turner <dturner@twopensource.com>
Cc: git@vger.kernel.org, mhagger@alum.mit.edu
Subject: Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs
Date: Wed, 08 Jul 2015 23:14:55 +0200 [thread overview]
Message-ID: <559D92CF.7000408@kdbg.org> (raw)
In-Reply-To: <1436382962.4542.8.camel@twopensource.com>
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 <dturner@twopensource.com>
>>> ---
>> ...
>>> 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
next prev parent reply other threads:[~2015-07-08 21:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 0:55 [PATCH v7 1/8] refs.c: add err arguments to reflog functions David Turner
2015-07-08 0:55 ` [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs David Turner
2015-07-08 17:46 ` Johannes Sixt
2015-07-08 19:16 ` David Turner
2015-07-08 21:14 ` Johannes Sixt [this message]
2015-07-08 23:23 ` Junio C Hamano
2015-07-08 23:44 ` David Turner
2015-07-09 5:55 ` Junio C Hamano
2015-07-09 21:53 ` David Turner
2015-07-09 22:06 ` Junio C Hamano
2015-07-10 4:30 ` Michael Haggerty
2015-07-10 17:59 ` David Turner
2015-07-14 4:33 ` David Turner
2015-07-15 16:24 ` Junio C Hamano
2015-07-15 18:04 ` David Turner
2015-07-08 23:41 ` David Turner
2015-07-08 0:55 ` [PATCH v7 3/8] bisect: treat BISECT_HEAD as a ref David Turner
2015-07-08 0:55 ` [PATCH v7 4/8] refs: Break out check for reflog autocreation David Turner
2015-07-08 0:56 ` [PATCH v7 5/8] refs: new public ref function: safe_create_reflog David Turner
2015-07-08 11:49 ` Michael Haggerty
2015-07-08 0:56 ` [PATCH v7 6/8] git-reflog: add exists command David Turner
2015-07-08 0:56 ` [PATCH v7 7/8] update-ref and tag: add --create-reflog arg David Turner
2015-07-08 13:44 ` Michael Haggerty
2015-07-08 20:21 ` David Turner
2015-07-08 0:56 ` [PATCH v7 8/8] git-stash: use update-ref --create-reflog instead of creating files David Turner
2015-07-08 7:28 ` Junio C Hamano
2015-07-08 7:33 ` Junio C Hamano
2015-07-08 13:50 ` Michael Haggerty
2015-07-08 11:36 ` [PATCH v7 1/8] refs.c: add err arguments to reflog functions Michael Haggerty
2015-07-08 20:01 ` David Turner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559D92CF.7000408@kdbg.org \
--to=j6t@kdbg.org \
--cc=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.