On 2018-09-24 02:08 PM, Ævar Arnfjörð Bjarmason wrote:
[...]
> Posting to this mailing list is generally how it's done
Thank you, Ævar, for clarifying that there is no issue tracker for the
git project.
> The best way to fix stuff in git that you can't interest others in is to
> do it yourself.
On 2018-09-24 03:24 PM, Philip Oakley wrote:
> Rather than attaching the problem with code, I decided to simply update
> the config file documentation.
>
> As the userbase expands the documentation will need to be more comprehensive
> about exclusions and omissions, along with better highlighting
Rather than attaching the problem with code, I decided to simply update
the config file documentation.
As the userbase expands the documentation will need to be more comprehensive
about exclusions and omissions, along with better highlighting for core
areas.
I would be useful if Stas could commen
On Sun, Sep 23 2018, Stas Bekman wrote:
> Apologies for I don't know how this project manages issues, so I'm not
> sure whether it is my responsibility to make sure this issue gets
> resolved, or do you have some tracking mechanism where you have it
> registered? There is no rush, I'm asking bec
Apologies for I don't know how this project manages issues, so I'm not
sure whether it is my responsibility to make sure this issue gets
resolved, or do you have some tracking mechanism where you have it
registered? There is no rush, I'm asking because the discussion about
this issue has suddenly d
On Tue, Sep 11, 2018 at 01:36:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think that's syntactically invalid. At any rate, there are clearly
> > three options for setting a bit:
> >
> > 1. In the section header (+include, or Ævar's includeIf suggestion).
> >
> > 2. In anoth
Jeff King writes:
> I think that's syntactically invalid. At any rate, there are clearly
> three options for setting a bit:
>
> 1. In the section header (+include, or Ævar's includeIf suggestion).
>
> 2. In another key (which looks pretty clean, but does introduce
> ordering constraints)
Stas Bekman writes:
> [include]
> path = .gitconfig
>
> Not realizing that the two were not in the same folder. And probably
> assuming that .git/config was referring to the root of repository, and
> not relative to .git/, which is a reasonable assumption.
>
> Of course he had no way of resol
To add another report of a similar problem, of silent skipping and not
of filepath quoting, I found this one:
https://stackoverflow.com/questions/31203634/git-clean-filter-python-script-on-windows/52264440#52264440
The user created .gitconfig and added to .git/config:
[include]
path = .gitco
Jonathan Nieder writes:
> Updated proposal:
>
> 1. Treat strings starting or ending with single-quote as worth
> quoting in config.c::write_pair (line 3269). This would already
> help with the original issue, since the config would say
>
> [foo]
> bar = "'baz'"
>
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> 1. Treat single-quote as worth quoting in config.c::write_pair (line
>> 2516). This would already help with the original issue, since the
>> config would say
>>
>> [foo]
>> bar = \'baz\'
>>
>> allowing a quick diag
Jonathan Nieder writes:
> 1. Treat single-quote as worth quoting in config.c::write_pair (line
> 2516). This would already help with the original issue, since the
> config would say
>
> [foo]
> bar = \'baz\'
>
> allowing a quick diagnosis.
I am mildly against th
Hi,
Junio C Hamano wrote:
> Jeff King writes:
>> So I think it's been covered elsewhere that single quotes aren't a thing
>> in git's config format. I will say that this was actually a minor
>> surprise to me, after a decade of working with the format. ;)
>>
>> I don't know if it's worth changin
Jeff King writes:
> On Sat, Sep 08, 2018 at 11:58:47AM -0700, Stas Bekman wrote:
>
>> This doesn’t:
>>
>> [include]
>> path = '../.gitconfig'
>
> So I think it's been covered elsewhere that single quotes aren't a thing
> in git's config format. I will say that this was actually a minor
>
On Sat, 2018-09-08 at 13:13 -0700, Stas Bekman wrote:
> I remind that the original problem came from a simple command:
>
> git config --local include.path '../.gitconfig'
>
> Which on linux removed the quotes and all was fine, and on windows
> the same command kept the quotes and the user was te
On 2018-09-08 07:51 PM, Paul Smith wrote:
[...]
> What I personally think would be more useful would be some sort of
> "verbose parsing" option to git config, that would parse the
> configuration just as a normal Git command would and show diagnostic
> output as the entire config is parsed: for eac
On Sat, Sep 08, 2018 at 11:10:44PM +0100, Ramsay Jones wrote:
> > Probably:
> >
> > [include]
> > warnOnMissing = false
> > path = ...
>
> I was going to suggest, inspired by Makefile syntax, that
> [-include] would not complain if the file was missing ...
> except, of course, it's too lat
On Sat, Sep 08, 2018 at 03:49:01PM -0700, Stas Bekman wrote:
> On 2018-09-08 02:22 PM, Jeff King wrote:
> [...]
> >> The original problem cropped up due to using:
> >>
> >> git config --local include.path '../.gitconfig'
> >>
> >> which on linux stripped the single quotes, but on some windows git
On Sun, Sep 09, 2018 at 12:32:57AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > You could even do:
> >
> > [include]
> > warnOnMissing = false
> > path = one
> > warnOnMissing = true
> > path = two
> >
> > to treat two includes differently (though I'm not sure why you would
> > want to).
>
On 2018-09-08 02:22 PM, Jeff King wrote:
[...]
>> The original problem cropped up due to using:
>>
>> git config --local include.path '../.gitconfig'
>>
>> which on linux stripped the single quotes, but on some windows git bash
>> emulation it kept them.
>
> That sounds like a bug in git bash, if
On Sat, Sep 08 2018, Jeff King wrote:
> On Sat, Sep 08, 2018 at 09:54:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> The reason missing includes are ignored is that the way this is expected
>> to be used is e.g.:
>>
>> [include]
>> path ~/.gitconfig.work
>>
>> Where .gitconfig.work
On 08/09/18 22:14, Jeff King wrote:
> On Sat, Sep 08, 2018 at 09:54:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> The reason missing includes are ignored is that the way this is expected
>> to be used is e.g.:
>>
>> [include]
>> path ~/.gitconfig.work
>>
>> Where .gitconfig.work i
On Sat, Sep 08, 2018 at 11:58:47AM -0700, Stas Bekman wrote:
> This doesn’t:
>
> [include]
> path = '../.gitconfig'
So I think it's been covered elsewhere that single quotes aren't a thing
in git's config format. I will say that this was actually a minor
surprise to me, after a decade of
On Sat, Sep 08, 2018 at 09:54:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
> The reason missing includes are ignored is that the way this is expected
> to be used is e.g.:
>
> [include]
> path ~/.gitconfig.work
>
> Where .gitconfig.work is some configuration you're going to drop into
>
On 2018-09-08 01:28 PM, Ævar Arnfjörð Bjarmason wrote:
[...]
> Yeah, some version of this is sensible. There's at least a doc patch in
> here somewhere, if not some "warn if missing" mode.
>
> So don't take any of this as minimizing that aspect of your bug report.
>
> *But*
>
> There's just no w
On Sat, Sep 08 2018, Stas Bekman wrote:
> On 2018-09-08 01:02 PM, Ævar Arnfjörð Bjarmason wrote:
>
>> Aside from other issues here, in the "wold of unix" (not that we only
>> use the git config syntax on those sort of systems) you can't assume
>> that just because some quoting construct works in
On Sat, Sep 08 2018, Stas Bekman wrote:
> On 2018-09-08 12:54 PM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Sat, Sep 08 2018, Martin Ågren wrote:
>>
>>> Hi Stas
>>>
>>> On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote:
[include]
path = '../.gitconfig'
Notice the single q
On 2018-09-08 01:02 PM, Ævar Arnfjörð Bjarmason wrote:
> Aside from other issues here, in the "wold of unix" (not that we only
> use the git config syntax on those sort of systems) you can't assume
> that just because some quoting construct works in the shell, that it
> works the same way in some
On 2018-09-08 12:54 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Sep 08 2018, Martin Ågren wrote:
>
>> Hi Stas
>>
>> On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote:
>>> [include]
>>> path = '../.gitconfig'
>>>
>>> Notice the single quotes around the filename. When this is the case git
On Sat, Sep 08 2018, Stas Bekman wrote:
> On 2018-09-08 12:30 PM, Martin Ågren wrote:
>> Hi Stas
>>
>> On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote:
>>> [include]
>>> path = '../.gitconfig'
>
>> Actually, there is a test explicitly testing that 'missing include files
>> are ignored'.
On Sat, Sep 08 2018, Martin Ågren wrote:
> Hi Stas
>
> On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote:
>> [include]
>> path = '../.gitconfig'
>>
>> Notice the single quotes around the filename. When this is the case git
>> silently (!) ignores the custom configuration, which is clearly
On 2018-09-08 12:30 PM, Martin Ågren wrote:
> Hi Stas
>
> On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote:
>> [include]
>> path = '../.gitconfig'
> Actually, there is a test explicitly testing that 'missing include files
> are ignored'. I couldn't find a motivation for this in 9b25a0b52e
On 2018-09-08 12:30 PM, Martin Ågren wrote:
> Actually, there is a test explicitly testing that 'missing include files
> are ignored'. I couldn't find a motivation for this in 9b25a0b52e
> (config: add include directive, 2012-02-06).
Thank you for the follow up, Martin. And discovering that it is
Hi Stas
On Sat, 8 Sep 2018 at 21:00, Stas Bekman wrote:
> [include]
> path = '../.gitconfig'
>
> Notice the single quotes around the filename. When this is the case git
> silently (!) ignores the custom configuration, which is clearly a bug.
Thanks for reporting and describing out your e
Hi,
One of the windows users discovered this bug, and I was able to
reproduce it on linux.
We are using a custom content filter configuration REPO/.gitconfig which
needs to be enabled inside REPO/.git/config:
This works:
[include]
path = ../.gitconfig
This doesn’t:
[include]
p
35 matches
Mail list logo
