Re: Missing git options

2018-02-06 Thread Jonathan Nieder
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

2018-02-06 Thread Duy Nguyen
On Tue, Feb 6, 2018 at 6:13 PM, Martin Häcker
 wrote:
> 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

2018-02-06 Thread Martin Häcker
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

2018-02-05 Thread brian m. carlson
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

2018-02-05 Thread Ævar Arnfjörð Bjarmason

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

2018-02-05 Thread Junio C Hamano
Stefan Beller  writes:

> 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

2018-02-05 Thread Stefan Beller
On Mon, Feb 5, 2018 at 1:12 AM, 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?

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

2018-02-05 Thread Martin Häcker
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

2015-10-28 Thread Peter Wu
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

2015-10-28 Thread Peter Wu
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

2013-06-28 Thread John Keeping
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

2013-06-22 Thread John Keeping
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

2013-06-22 Thread SZEDER Gábor
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

2013-06-22 Thread SZEDER Gábor
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