Phil Hord wrote:
> Junio C Hamano wrote:
>> Phil Hord <ho...@cisco.com> writes:
>>> State token strings which may be emitted and their meanings:
>>> merge a merge is in progress
>>> am an am is in progress
>>> am-is-empty the am patch is empty
>>> rebase a rebase is in progress
>>> rebase-interactive an interactive rebase is in progress
>>> cherry-pick a cherry-pick is in progress
>>> bisect a bisect is in progress
>>> conflicted there are unresolved conflicts
>>> commit-pending a commit operation is waiting to be completed
>>> splitting interactive rebase, commit is being split
>>> I also considered adding these tokens, but I decided it was not
>>> appropriate since these changes are not sequencer-related. But
>>> it is possible I am being too short-sighted or have chosen the
>>> switch name poorly.
>>> changed-index Changes exist in the index
>>> changed-files Changes exist in the working directory
>>> untracked New files exist in the working directory
>> I tend to agree; unlike all the normal output from "status -s" that
>> are per-file, the above are the overall states of the working tree.
>> It is just that most of the "overall states" look as if they are
>> dominated by "sequencer states", but that is only because you chose
>> to call states related to things like "am" and "bisect" that are not
>> sequencer states as such.
>> It probably should be called the tree state, working tree state, or
> I think you are agreeing that I chose the switch name poorly, right?
> Do you think '--tree-state' is an acceptable switch or do you have other
I've been calling these 'tokens' myself. A token is a word-or-phrase I
can parse easily with the default $IFS, for simpler script handling.
I'm happy to make that official and use --tokens and -T, but I suspect a
more appropriate name is available.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html