Re: Missing git options
Hi, Martin Häcker wrote: >> Am 06.02.2018 um 01:43 schrieb brian m. carlson >>: >> I think this is likely to cause problems. Many people use git log with >> --pretty to format commit hashes or messages into other programs. I'm >> aware of multiple tools that will simply break if --graph or --patch >> become the default. Requiring people to retrofit their tools to use >> --no-graph or --no-patch is likely to be a burden. > > While I share your concern, this is something that will completely > freeze development of the git tui which I cannot imagine is wanted. On the contrary, we take things on a case by case basis. Brian described a cost to your proposed change and you described a benefit; the next step would be to figure out a way to accomplish what you're aiming to do in a way that maximizes the benefit and minimizes the cost. In other words, it is not that we never change default output formats, but we do care a lot about helping existing users. One way of doing that is to provide more convenient machine-readable versions of some commands so that it is obvious to script writers what to use. As Stefan Beller mentioned, "git log" is in interesting case, in that the scripting commands exist: - "git rev-list" to list commits satisfying some criteria - "git diff-tree --stdin" to show information about those commits But these commands were not sufficiently discoverable and easy to use, so people end up using "git log" for scripting anyway. We provide - "git log --format" to produce log output with a fixed format, and in particular - "git log --format=raw" to print raw objects It's perfectly normal and common to change what "git log --format=medium" (the default format) prints, as long as we take into account the effect on existing users. In particular: - Some scripts do not care about the *exact* format from "git log" but are using the output for a particular purpose (e.g. to generate release notes that they distribute along with compiler output). If these scripts start _sometimes_ using --graph instead based on configuration, this would be disruptive to some users. - Making --format suppress `log.graph` configuration feels confusing and hard to explain to me. --graph --format= would mean something different from -c log.graph=true --format=, except when = medium, or "--format=medium" would mean something different from not specifying --format at all even though medium is the default format. In that context, it feels simpler to me to use aliases: [alias] l = log --oneline --graph --patch That way, it does not confuse scripts, and even better, it is easier to type, as "git l". I would be happy to see some documentation pointing users to the alias feature for this purpose. As an example of changing the default "git log" format, see the history in "git log --grep=decorate". I am all for that kind of change, but I don't think --graph or --patch falls into this category. Thanks and hope that helps, Jonathan
Re: Missing git options
On Tue, Feb 6, 2018 at 6:13 PM, Martin Häckerwrote: > This however still freezes the default output of git forever. Why is that a bad thing? Default output format should not change (much) from version to version, or from machine to machine (because of different ~/.gitconfig) for that matter. I don't want to type "git log" on somebody else's machine and have a big surprise. You _can_ customize output but that should be explicit. If you want good defaults, that's what aliases are for. I personally rarely type "git log". I have "l", "lp", "l1" and other aliases for my everyday use. -- Duy
Re: Missing git options
Hi all, > Am 06.02.2018 um 01:43 schrieb brian m. carlson >: > > I think this is likely to cause problems. Many people use git log with > --pretty to format commit hashes or messages into other programs. I'm > aware of multiple tools that will simply break if --graph or --patch > become the default. Requiring people to retrofit their tools to use > --no-graph or --no-patch is likely to be a burden. While I share your concern, this is something that will completely freeze development of the git tui which I cannot imagine is wanted. If this where my tool, I would much rather advertise an output format specifically for scripting. An interim solution could be something like an `—ignore-configuration` option that allows script writers to get predictable output. This however still freezes the default output of git forever. So you will need something like —output-for=scripting|json|xml|whatever sooner or later. Mixing up the TUI for humans and for scripts is not going to be fun to evolve. Best Regards, Martin Häcker signature.asc Description: Message signed with OpenPGP
Re: Missing git options
On Mon, Feb 05, 2018 at 10:12:05AM +0100, Martin Häcker wrote: > Hi there, > > I just recently learned that not all command line switches seem to > automatically correlate to options in the git configuration. > > This seems something that should be relatively easy to fix. > > What I’m most missing is > > — snip — > [log] > graph = true > patch = true > — snap — > > which would / should correspond to `git log —graph —patch`. > > What do you guys think? I think this is likely to cause problems. Many people use git log with --pretty to format commit hashes or messages into other programs. I'm aware of multiple tools that will simply break if --graph or --patch become the default. Requiring people to retrofit their tools to use --no-graph or --no-patch is likely to be a burden. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Re: Missing git options
On Mon, Feb 05 2018, Martin Häcker jotted: > Hi there, > > I just recently learned that not all command line switches seem to > automatically correlate to options in the git configuration. > > This seems something that should be relatively easy to fix. > > What I’m most missing is > > — snip — > [log] > graph = true > patch = true > — snap — > > which would / should correspond to `git log —graph —patch`. > > What do you guys think? FWIW my WIP https://public-inbox.org/git/20170328131316.32516-1-ava...@gmail.com/ had some discussion around this.
Re: Missing git options
Stefan Bellerwrites: > I had the impression that git-log was a pseudo-plumbing, > despite it being explicitly marked porcelain > as there is no good plumbing alternative. I do not think that is a fair assessment of the situation. The more troublesome is that depending on what exactly you want to do, you need to use a different plumbing command and/or combinations of them, which means people need to _learn_ Git scripting. We recently saw that somebody used "log -1 --pretty=format:%T $commit" when the code only needed to say "rev-parse --verify $commit^{tree}" and got broken due to end-user configuration ;-)
Re: Missing git options
On Mon, Feb 5, 2018 at 1:12 AM, Martin Häckerwrote: > Hi there, > > I just recently learned that not all command line switches seem to > automatically correlate to options in the git configuration. > > This seems something that should be relatively easy to fix. > > What I’m most missing is > > — snip — > [log] > graph = true > patch = true > — snap — > > which would / should correspond to `git log —graph —patch`. > > What do you guys think? Feel free to send patches adding these options. I had the impression that git-log was a pseudo-plumbing, despite it being explicitly marked porcelain as there is no good plumbing alternative. But as we already have things like log.date, log.decorate, that change the output of git-log, I think a patch or graph option would be ok. Thanks, Stefan
Missing git options
Hi there, I just recently learned that not all command line switches seem to automatically correlate to options in the git configuration. This seems something that should be relatively easy to fix. What I’m most missing is — snip — [log] graph = true patch = true — snap — which would / should correspond to `git log —graph —patch`. What do you guys think? Best Regards, Martin Häcker signature.asc Description: Message signed with OpenPGP
[PATCH 0/3] bash-completion fixes for global git options handling
Hi, These patches improve bash-completion when global git options are present. Consider this problem: bash-4.3$ git -C ../linux staerror: invalid key: alias.../linux This happens because the current script is unaware of the -C option. In general, global options are not handled well (patch 001 fixes this). Patch 2 makes the completions more aware of the --git-dir option. Patch 3 builds on previous patches and makes completions aware of the -C option. Kind regards, Peter Peter Wu (3): completion: ignore git options for subcommand completion completion: pass --git-dir to more commands completion: handle git -C option contrib/completion/git-completion.bash | 119 - 1 file changed, 72 insertions(+), 47 deletions(-) -- 2.6.1 -- 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
[PATCH 1/3] completion: ignore git options for subcommand completion
Do not assume that the first option after "git" is a subcommand. This fixes completion such as: # do not detect "push" as remote name git --git-dir=git/.git push origin # do not overwrite "--git-dir=..." with the alias expansion git --git-dir=git/.git gerrit-diff Signed-off-by: Peter Wu--- contrib/completion/git-completion.bash | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 482ca84..bd9ef4c 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -531,8 +531,8 @@ __git_complete_revlist () __git_complete_remote_or_refspec () { - local cur_="$cur" cmd="${words[1]}" - local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0 + local cur_="$cur" cmd="${words[command_word_index]}" + local i c=$((command_word_index+1)) remote="" pfx="" lhs=1 no_complete_refspec=0 if [ "$cmd" = "remote" ]; then ((c++)) fi @@ -788,7 +788,7 @@ __git_aliased_command () # __git_find_on_cmdline requires 1 argument __git_find_on_cmdline () { - local word subcommand c=1 + local word subcommand c=$command_word_index while [ $c -lt $cword ]; do word="${words[c]}" for subcommand in $1; do @@ -803,7 +803,7 @@ __git_find_on_cmdline () __git_has_doubledash () { - local c=1 + local c=$command_word_index while [ $c -lt $cword ]; do if [ "--" = "${words[c]}" ]; then return 0 @@ -826,8 +826,8 @@ __git_count_arguments () { local word i c=0 - # Skip "git" (first argument) - for ((i=1; i < ${#words[@]}; i++)); do + # Skip "git" (first argument) and any options such as --git-dir. + for ((i=command_word_index; i < ${#words[@]}; i++)); do word="${words[i]}" case "$word" in @@ -957,7 +957,7 @@ _git_bisect () _git_branch () { - local i c=1 only_local_ref="n" has_r="n" + local i c=$command_word_index only_local_ref="n" has_r="n" while [ $c -lt $cword ]; do i="${words[c]}" @@ -992,7 +992,7 @@ _git_branch () _git_bundle () { - local cmd="${words[2]}" + local cmd="${words[command_word_index+1]}" case "$cword" in 2) __gitcomp "create list-heads verify unbundle" @@ -1760,7 +1760,7 @@ _git_stage () __git_config_get_set_variables () { local prevword word config_file= c=$cword - while [ $c -gt 1 ]; do + while [ $c -gt $command_word_index ]; do word="${words[c]}" case "$word" in --system|--global|--local|--file=*) @@ -2516,7 +2516,7 @@ _git_svn () _git_tag () { - local i c=1 f=0 + local i c=$command_word_index f=0 while [ $c -lt $cword ]; do i="${words[c]}" case "$i" in @@ -2562,7 +2562,7 @@ _git_whatchanged () __git_main () { - local i c=1 command __git_dir + local i c=1 command command_word_index __git_dir while [ $c -lt $cword ]; do i="${words[c]}" @@ -2573,7 +2573,7 @@ __git_main () --help) command="help"; break ;; -c|--work-tree|--namespace) ((c++)) ;; -*) ;; - *) command="$i"; break ;; + *) command="$i"; command_word_index=$c; break ;; esac ((c++)) done @@ -2608,7 +2608,7 @@ __git_main () local expansion=$(__git_aliased_command "$command") if [ -n "$expansion" ]; then - words[1]=$expansion + words[command_word_index]=$expansion completion_func="_git_${expansion//-/_}" declare -f $completion_func >/dev/null && $completion_func fi -- 2.6.1 -- 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: [PATCH 1/2] completion: handle unstuck form of base git options
Hi Junio, I don't think you've picked this up. Are you expecting a re-roll or did it just get lost in the noise? On Sat, Jun 22, 2013 at 12:25:17PM +0100, John Keeping wrote: git-completion.bash's parsing of the command name relies on everything preceding it starting with '-' unless it is the -c option. This allows users to use the stuck form of --work-tree=path and --namespace=path but not the unstuck forms --work-tree path and --namespace path. Fix this. Similarly, the completion only handles the stuck form --git-dir=path and not --git-dir path, so fix this as well. Signed-off-by: John Keeping j...@keeping.me.uk --- contrib/completion/git-completion.bash | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6c3bafe..8fbf941 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2492,9 +2492,10 @@ __git_main () i=${words[c]} case $i in --git-dir=*) __git_dir=${i#--git-dir=} ;; + --git-dir) ((c++)) ; __git_dir=${words[c]} ;; --bare) __git_dir=. ;; --help) command=help; break ;; - -c) c=$((++c)) ;; + -c|--work-tree|--namespace) ((c++)) ;; -*) ;; *) command=$i; break ;; esac -- 1.8.3.1.676.gaae6535 -- 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
[PATCH 1/2] completion: handle unstuck form of base git options
git-completion.bash's parsing of the command name relies on everything preceding it starting with '-' unless it is the -c option. This allows users to use the stuck form of --work-tree=path and --namespace=path but not the unstuck forms --work-tree path and --namespace path. Fix this. Similarly, the completion only handles the stuck form --git-dir=path and not --git-dir path, so fix this as well. Signed-off-by: John Keeping j...@keeping.me.uk --- contrib/completion/git-completion.bash | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6c3bafe..8fbf941 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2492,9 +2492,10 @@ __git_main () i=${words[c]} case $i in --git-dir=*) __git_dir=${i#--git-dir=} ;; + --git-dir) ((c++)) ; __git_dir=${words[c]} ;; --bare) __git_dir=. ;; --help) command=help; break ;; - -c) c=$((++c)) ;; + -c|--work-tree|--namespace) ((c++)) ;; -*) ;; *) command=$i; break ;; esac -- 1.8.3.1.676.gaae6535 -- 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: [PATCH 1/2] completion: handle unstuck form of base git options
Hi, On Sat, Jun 22, 2013 at 12:25:17PM +0100, John Keeping wrote: git-completion.bash's parsing of the command name relies on everything preceding it starting with '-' unless it is the -c option. This allows users to use the stuck form of --work-tree=path and --namespace=path but not the unstuck forms --work-tree path and --namespace path. Fix this. I never use these commands, so I looked up what --namespace means. While doing so I noticed that --exec-path takes a path just like these options, so that option should be handled similarly as well. Otherwise it makes sense. Gábor Similarly, the completion only handles the stuck form --git-dir=path and not --git-dir path, so fix this as well. Signed-off-by: John Keeping j...@keeping.me.uk --- contrib/completion/git-completion.bash | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6c3bafe..8fbf941 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2492,9 +2492,10 @@ __git_main () i=${words[c]} case $i in --git-dir=*) __git_dir=${i#--git-dir=} ;; + --git-dir) ((c++)) ; __git_dir=${words[c]} ;; --bare) __git_dir=. ;; --help) command=help; break ;; - -c) c=$((++c)) ;; + -c|--work-tree|--namespace) ((c++)) ;; -*) ;; *) command=$i; break ;; esac -- 1.8.3.1.676.gaae6535 -- 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: [PATCH 1/2] completion: handle unstuck form of base git options
On Sat, Jun 22, 2013 at 02:30:33PM +0200, SZEDER Gábor wrote: Hi, On Sat, Jun 22, 2013 at 12:25:17PM +0100, John Keeping wrote: git-completion.bash's parsing of the command name relies on everything preceding it starting with '-' unless it is the -c option. This allows users to use the stuck form of --work-tree=path and --namespace=path but not the unstuck forms --work-tree path and --namespace path. Fix this. I never use these commands, so I looked up what --namespace means. While doing so I noticed that --exec-path takes a path just like these options, so that option should be handled similarly as well. Never mind, I misunderstood the docs: --exec-path either takes a path as --exec-path=path or it doesn't take one at all, but there is no '--exec-path path'. Gábor -- 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