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

Re: Missing git options

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

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

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

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 —

Re: Missing git options

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

Re: Missing git options

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. > >

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 —

[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

[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:

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

[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.

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

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