Re: [PATCHv5 1/3] wt-status.*: better advices for git status added

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 1, 2012, 12:40 UTC
Message-ID: <CABURp0rm2JKBmrm62uAVj1WSc3BE_LoKoHbjmxvkQhPNgnozpA@mail.gmail.com>
In-Reply-To: <20120601132710.Horde.j1U5UHwdC4BPyKcOgc8zbbA@webmail.minatec.grenoble-inp.fr>

On Fri, Jun 1, 2012 at 7:27 AM,  <konglu@minatec.inpg.fr> wrote:

Show 28 quoted lines

>
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> a écrit :
>
>>> +    if (state->merge_in_progress)
>>> +            merge_in_progress_show(s, state, state_color);
>>> +    else if (state->am_in_progress)
>>> +            am_in_progress_show(s, state, state_color);
>>> +    else if (state->rebase_in_progress ||
>>> state->rebase_interactive_in_progress)
>>> +            rebase_in_progress_show(s, state, state_color);
>>> +    else if (state->cherry_pick_in_progress)
>>> +            cherry_pick_in_progress_show(s, state, state_color);
>>> +    if (state->bisect_in_progress)
>>> +            bisect_in_progress_show(s, state, state_color);
>>
>> I still disagree with the "else if" logic here. If the user started two
>> operations, I think we should show both messages.
>
> We show both messages in the case of bisect. However, we decided to
> implement a priority for the other cases because of how the code figures
> out the current state.
> The cases in which you're in 'am' AND 'rebase' or only in 'am' is hard to
> handle. Thus The priority is given to the 'am' because running 'am' during
> a 'rebase' is possible (and the other way is not).
> On top of that, I think that the user only needs to know his "most recent"
> current state. Given that he's running 'am' during a 'rebase', knowing that
> he's in am progress is enough. If he finishes the 'am', then he will still
> know that he's in a 'rebase' with 'git status'.

Related to this, I think this is all useful information which is being gathered and analyzed here. It would be useful if all of the git code could use these status functions in common instead of implementing similar functionality individually. But that is a topic for another commit.

More appropriate for now is that I think there should be a porcelain(?) version of this information. First, imagine we can get just this new session status information with a switch named '--sequencer'[*]::

  $ git status --sequencer
  You have unmerged paths.
  You are in an am session.
  You are in the middle of an interactive rebase.

  $ git status --porcelain --sequencer
  airu

The "--porcelain --sequencer" combination I am imagining here would
show the status as a script-parseable sequence of single-letter
indicators telling the status of these same various conditions:
  u - unmerged paths
  a - git-am session
  i - interactive rebase
  r - rebase
  c - cherry-pick
  m - merge
etc.

By giving a value to --porcelain, we could limit the test to certain conditions and return a meaningful result code if any are true.

  $ if git status --porcelain --sequencer=u ; then echo "Unmerged
paths exist" ; fi

I don't know if it makes sense to spell the --porcelain version with or without spaces/newlines. Any opinions?

What about the idea overall?

Phil

[*] Though I hate the choice of 'sequencer' as an option name for the user, it makes sense to me in this context. Please suggest any alternatives that spring to mind.