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 --
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 d
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 d
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 miss
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 —
>
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
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
>
> —
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 —
whic
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
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:
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
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 t
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=" and
> "--namespace=" but not the un
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=" and
"--namespace=" but not the unstuck forms "--work-tree " and
"--namespace ". Fix this.
Similarly, the c
Would it be useful at this point to make common and centralize some/most
of the various options that control git? (as well as add some useful
ones). Something like:
struct _git_opt {
int verbose:1;
int debug:1;
int dry-run:1;
int should_block:1;
int remove
15 matches
Mail list logo