From: Phil Hord <hordp@cisco.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: "phil.hord@gmail.com" <phil.hord@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
"konglu@minatec.inpg.fr" <konglu@minatec.inpg.fr>,
Kong Lucien <Lucien.Kong@ensimag.imag.fr>,
"git@vger.kernel.org" <git@vger.kernel.org>,
Duperray Valentin <Valentin.Duperray@ensimag.imag.fr>,
Jonas Franck <Franck.Jonas@ensimag.imag.fr>,
Nguy Thomas <Thomas.Nguy@ensimag.imag.fr>,
Nguyen Huynh Khoi Nguyen
<Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Subject: Re: [PATCH] git-status: show short sequencer state
Date: Tue, 23 Oct 2012 14:03:07 -0400 [thread overview]
Message-ID: <5086DBDB.9070606@cisco.com> (raw)
In-Reply-To: <vpqsj95soxp.fsf@grenoble-inp.fr>
Matthieu Moy wrote:
> Phil Hord <hordp@cisco.com> writes:
>
>> + merge a git-merge is in progress
>> + am a git-am is in progress
>> + rebase a git-rebase is in progress
>> + rebase-interactive a git-rebase--interactive is in progress
>> + cherry-pick a git-cherry-pick is in progress
>> + bisect a git-bisect is in progress
> Avoid using git-foo syntax in documentation, it suggests that this is
> valid command, which isn't true anymore. `git foo` seems the most common
> syntax. Also, git-rebase--interactive is not user-visible => `git rebase
> --interactive`.
Thanks.
>> - if (state->am_empty_patch)
>> + if (state->substate==WT_SUBSTATE_NOMINAL)
>> status_printf_ln(s, color,
>> _("The current patch is empty."));
> This looks weird. First, spaces around == (here and below). Then, the
> logic is unintuitive. The "if" suggests everything is allright, and the
> message below is very specific. This at least deserves a comment.
Yes, I agree. It was less clear but more reasonable before I tried to
clear it up some. It's driven by the short-token printer. The state is
"you're in a 'git am' but I do not see any conflicted files. Therefore,
your patch must be empty." I suspect this may be a leaving from the
git-am machinery where it did not choose to clean up after itself if the
patch was empty, but perhaps it should have. I seldom use git-am, so I
do not know if this code reflects a common and useful state.
I'll try to make this more explicit. Currently the short-status
version will say either "am" or "am \n conflicted" when a 'git am' is in
progress. The logical path to follow if I re-add 'git-am-empty' state
tracker is for this to now show either "am \n am-is-empty" or "am \n
conflicted". But I think I should suppress the "am-is-empty" report in
that case. What do you think
>> if (advice_status_hints) {
>> - if (!state->am_empty_patch)
>> + if (state->substate==WT_SUBSTATE_CONFLICTED)
> Spaces around ==.
>
>> +static void wt_print_token(struct wt_status *s, const char *color, const char *token)
>> +{
>> + color_fprintf(s->fp, color, "%s", token);
>> + fputc(s->null_termination ? '\0' : '\n', s->fp);
>> +}
> The output format seems to be meant only for machine-consumption. Is
> there any case when we'd want color? I'd say we can disable coloring
> completely for this format (normally, color=auto does the right thing,
> but I prefer being 100% sure I'll get no color when writing scripts)
Originally I had this output nested in the normal 'git status --short'
output, like a shortened form of the "advice". Then, 'git-status
--porcelain' would show the tokens without color, but 'git status
--short' would show them with color. I thought I might be going back
there, or that I might combine this with full 'git status' again
somehow, and colors seemed appropriate still.
The --short status report is too confusing when tokens may or may-not
appear, and it would likely break some scripts, even though they should
be using --porcelain. And the full status already has its long versions
of the same text. So I can remove this color decorator until someone
finds a need for it.
>> +static void wt_shortstatus_print_sequencer(struct wt_status *s)
> [...]
>> +void wt_sequencer_print(struct wt_status *s)
>> +{
>> + wt_shortstatus_print_sequencer(s);
>> +}
>> +
> Why do you need this trivial wrapper?
Another left-over from its previous multiple versions. I'll simplify it.
> Other than that, I like the idea (although I have no concrete use-case
> in mind), but I didn't actually test the patch.
My own use-case involves $PS1. I keep running into "you cannot
cherry-pick because you are in the middle of a rebase" in submodules in
which I have long forgotten about the failed action and have gone on to
write many new commits, or switched branches, or worse. I do not know
what 'git rebase --abort' will give me in those cases, and I wonder what
work I might have lost for having been interrupted in the middle of that
action in the past. These tokens will help me decorate my prompt to
remind me I left some baggage untended.
Thanks for the feedback.
Phil
next prev parent reply other threads:[~2012-10-23 18:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 23:29 [PATCH] git-status: show short sequencer state Phil Hord
2012-10-23 6:05 ` Matthieu Moy
2012-10-23 18:03 ` Phil Hord [this message]
2012-10-24 8:15 ` Matthieu Moy
-- strict thread matches above, loose matches on Subject: below --
2012-10-23 18:58 Phil Hord
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=5086DBDB.9070606@cisco.com \
--to=hordp@cisco.com \
--cc=Franck.Jonas@ensimag.imag.fr \
--cc=Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr \
--cc=Lucien.Kong@ensimag.imag.fr \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=Thomas.Nguy@ensimag.imag.fr \
--cc=Valentin.Duperray@ensimag.imag.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=konglu@minatec.inpg.fr \
--cc=phil.hord@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).