Re: [PATCHv3 3/4] git-status: show short sequencer state
Junio C Hamano wrote: Phil Hord ho...@cisco.com writes: Do you think '--tree-state' is an acceptable switch or do you have other suggestions? 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. That name may be good for variables, but it is good only because you as the implementor know what purpose the tokens are used for. Instead of having to call them with a longer name, e.g. state tokens, only because you know that these tokens represent tree-wide (as opposed to per-file) state, you can call them tokens in your implementation (and in your head) without confusing yourself. To the end users who should not care about the implementation detail, it is not a good name at all. The UI should surface the purpose, i.e. what these tokens are used for, (e.g. to represent tree-wide state) more than the fact that you happened to represent them with a single short word (i.e. token). So --show-tree-state, --include-tree-state-in-the-output or something along that line that tells the user what the option is about is more preferable than --token. After all, you may want to use tokens to represent different kind of information in a later topic that is not about a tree-wide state, and you will regret that you used --token for this particular feature at that time. I don't think I would regret it at all. I do not expect to conflate the word tokens with the meaning show-tree-state. It only has this meaning because it is part 'git status'. If I want to show a different kind of tokens in the future, I think --tokens would still work fine there. It would even have precedent. Consider the usage: git status # show work-tree status git status --short # show short work-tree status git status --tokens # show work-tree status in token form In the future if someone adds a similar operation to another command,I do not think it would be confusing if it had a similar result. git log --tokens git show-ref --tokens HEAD But maybe --tokens has some better meaning that someone will want to use in the future. I'm not married to it. But git status already means Show the working tree status. So git status --show-tree-state sounds redundant or meaningless. 'git status' already recognizes switches --ignored and --branch, for example, to add extra state information to the output. I want to add tree-state tokens to the list. But I don't know a better name for them. Perhaps --show-tree-state is sufficient. Still sounds redundant to me. Phil -- 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
Re: [PATCHv3 3/4] git-status: show short sequencer state
Phil Hord ho...@cisco.com writes: Consider the usage: git status # show work-tree status git status --short # show short work-tree status git status --tokens # show work-tree status in token form OK, your --tokens is more about *how* things are output, but it is unclear how it would interact with --short. I had an impression that you are basing your output on the short output, whose existing record include ## (that shows the branch names and states), and MM, A and friends (that show the per-file states), by adding new record types that shows tree-wide states. But maybe --tokens has some better meaning that someone will want to use in the future. I'm not married to it. But git status already means Show the working tree status. So git status --show-tree-state sounds redundant or meaningless. I didn't mean to say that you have to spell out all these words; show and state are redundant. The important part is that unlike the existing per-file state the status command is showing, the option is to add tree-wide state to the output, and my suggestion was to pick a word that makes it clear, rather than using output is done using tokens without saying what is being output in tokenized form. -- 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
Re: [PATCHv3 3/4] git-status: show short sequencer state
Junio C Hamano wrote: Phil Hord ho...@cisco.com writes: Consider the usage: git status # show work-tree status git status --short # show short work-tree status git status --tokens # show work-tree status in token form OK, your --tokens is more about *how* things are output, but it is unclear how it would interact with --short. I had an impression that you are basing your output on the short output, whose existing record include ## (that shows the branch names and states), and MM, A and friends (that show the per-file states), by adding new record types that shows tree-wide states. I am, but I don't much care for the ## prefix, especially when combined with --null, for example. I'm inclined to remove it when --short is not provided, specifically to give scripts an easier time of parsing. But scripts are likely to need --porcelain as well, and currently that implies --short. But I suppose another combination could be meaningful. # tokens only $ git status --tree changed-files # tokens and short-status $ git status --tree --short ## changed-files M foo.txt # short-status only $ git status --porcelain M foo.txt # tokens only? $ git status --tree --porcelain changed-files I think this spaghettify's the ui too much. Maybe this instead: # undecorated tokens only $ git status --tree=porcelain changed-files But maybe --tokens has some better meaning that someone will want to use in the future. I'm not married to it. But git status already means Show the working tree status. So git status --show-tree-state sounds redundant or meaningless. I didn't mean to say that you have to spell out all these words; show and state are redundant. The important part is that unlike the existing per-file state the status command is showing, the option is to add tree-wide state to the output, and my suggestion was to pick a word that makes it clear, rather than using output is done using tokens without saying what is being output in tokenized form. Thanks for clarifying. Phil -- 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
Re: [PATCHv3 3/4] git-status: show short sequencer state
Junio C Hamano gits...@pobox.com writes: Phil Hord ho...@cisco.com writes: # tokens and short-status $ git status --tree --short ## changed-files M foo.txt Hrm, how will the existing readers of the output avoid getting confused by this overloading of ##, which has meant the current branch information? That was a stupid question. Existing readers do not know to give --tree to the command, so they are perfectly OK. It is however not OK for new readers that wants to read these tree-wide state and also branch information. -- 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
Re: [PATCHv3 3/4] git-status: show short sequencer state
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-emptythe am patch is empty rebase a rebase is in progress rebase-interactive an interactive rebase is in progress cherry-picka 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 somesuch. 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 suggestions? 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. Phil -- 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
Re: [PATCHv3 3/4] git-status: show short sequencer state
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-emptythe am patch is empty rebase a rebase is in progress rebase-interactive an interactive rebase is in progress cherry-picka 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 somesuch. -- 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
Re: [PATCHv3 3/4] git-status: show short sequencer state
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-emptythe am patch is empty rebase a rebase is in progress rebase-interactive an interactive rebase is in progress cherry-picka 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 somesuch. 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 suggestions? Phil -- 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
