On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote:
> In any case, hopefully we can fix this before the final, as this is
> a regression introduced during this cycle?
I think I am going to stop at the v4. Unless there are some
corrections requested.
Before 817f7dc223, CONTENT_LENGTH variable was never considered,
http-backend was just reading request body from standard input until EOF
when it, or a command started by it, needed it.
Then it was discovered that some HTTP do not close standard input, instead
expecting CGI scripts to obey CONTENT
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
Am 08.09.2018 um 04:04 schrieb Junio C Hamano:
> Jonathan Nieder writes:
>
>> It is late in the release cycle, so revert the whole 3-patch series.
>> We can try again later for 2.20.
>>
>> Reported-by: Allan Sandfeld Jensen
>> Helped-by: Stefan Beller
>> Signed-off-by: Jonathan Nieder
>> ---
>
Am 08.09.2018 um 11:26 schrieb Johannes Sixt:
Am 07.09.2018 um 20:19 schrieb Jeff Hostetler via GitGitGadget:
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..ef03bbe5d2 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -355,7 +355,7 @@ static int mingw_open_append(wchar_t const
Le sam. 08 sept. 2018 à 19:15:32 +0200, Julien Moutinho a écrit :
> As a quick workaround this hotpatch can even be put in $GITWEB_CONFIG
> by removing the `local` before `*FCGI::Stream::PRINT`.
Turns out to require more care than that,
due to $per_request_config reloading $GITWEB_CONFIG at each r
Description
===
An old (2011) description of the problem is here:
https://stackoverflow.com/questions/7285215/nginx-fastcgi-utf-8-encoding-output-iso-8859-1-instead-of-utf8#answer-18149487
Basically, gitweb's HTML output is not always encoded in UTF-8
when using --fastcgi.
Reproduction
=
On Sat, 8 Sep 2018 at 16:04, Ben Peart wrote:
> On 9/8/2018 2:29 AM, Martin Ågren wrote:
> > Maybe it all works out, e.g., so that when someone (brian) merges a
> > NewHash and runs the testsuite, this will fail consistently and in a
> > safe way. But I wonder if it would be too hard to avoid the
On Fri, Sep 07, 2018 at 12:23:53AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
> > If this turns out to be a common use-case perhaps the easiest way to
> > support that would be to make the hashmap (optionally?) ordered, as Ruby
> > 1.9 did with their hash implementation:
> > htt
On Thu, Sep 6, 2018 at 4:48 AM SZEDER Gábor wrote:
>
> Ever since the split index feature was introduced [1], refreshing a
> split index is prone to a variant of the classic racy git problem.
>
> Consider the following sequence of commands updating the split index
> when the shared index contains
On Sat, Sep 08, 2018 at 03:34:34PM +0200, Duy Nguyen wrote:
> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
> >
> > Just printing the command that the user entered is not particularly
> > helpful when trying to find the alias that causes the loop.
> >
> > Print the history of substituted
On Sat, Sep 08, 2018 at 03:38:19PM +0200, Duy Nguyen wrote:
> On Fri, Sep 7, 2018 at 8:21 PM Jeff King wrote:
> >
> > We currently build cleanly with -Wformat-security, and it's
> > a good idea to make sure we continue to do so (since calls
> > that trigger the warning may be security vulnerabili
On Fri, Sep 07, 2018 at 11:28:41PM -0400, Todd Zullinger wrote:
> > So this fix looks fine. It might be worth a comment above the creation
> > of expect_cookies.txt to mention it must be in sorted order (of course
> > anybody modifying it would see a test failure).
>
> I thought about running the
On Sat, Sep 01, 2018 at 08:34:41PM -0400, Noam Postavsky wrote:
> On 6 August 2018 at 17:26, Jeff King wrote:
>
> > I suspect it still has a bug, which is that it is handling this
> > first-parent-goes-left case, but probably gets the straight-parent case
> > wrong. But at least in this form, I
On Sat, Sep 08, 2018 at 10:57:46AM +0200, Christian Couder wrote:
> On Thu, Sep 6, 2018 at 9:31 PM, Jeff King wrote:
> > On Thu, Sep 06, 2018 at 11:51:49AM +0200, Christian Couder wrote:
> >
> >> Yeah, I think the https://git.github.io/Outreachy-17/ is not actually
> >> necessary.
> >
> > I thin
On 9/7/2018 5:10 PM, Junio C Hamano wrote:
Ben Peart writes:
+struct load_index_extensions
+{
+#ifndef NO_PTHREADS
+ pthread_t pthread;
+#endif
+ struct index_state *istate;
+ void *mmap;
+ size_t mmap_size;
+ unsigned long src_offset;
If the file format only
On 9/8/2018 2:29 AM, Martin Ågren wrote:
On Fri, 7 Sep 2018 at 22:24, Ben Peart wrote:
Ben Peart writes:
- 160-bit SHA-1 over the extension types and their sizes (but not
their contents). E.g. if we have "TREE" extension that is N-bytes
long, "REUC" extension that is M-bytes long, follo
On Thu, Sep 6, 2018 at 4:48 AM SZEDER Gábor wrote:
>
> The test 'disable split index' in 't1700-split-index.sh' runs the
> following pipeline:
>
> cmd | grep | sed s///
>
> Drop that 'grep' from the pipeline, and let 'sed' take over its
> duties.
Years of using sed and I never realized -n coul
On Sat, Sep 8, 2018 at 3:09 PM Duy Nguyen wrote:
>
> On Sat, Sep 8, 2018 at 11:28 AM Hultqvist wrote:
> >
> > The bash commands are using a git and bash bundle that was installed
> > in parallel with gitextensions(a gui for git)
> >
> > G:\Min enhet> set GIT_TRACE_SETUP=1
> > G:\Min enhet> git st
On Fri, Sep 7, 2018 at 8:21 PM Jeff King wrote:
>
> We currently build cleanly with -Wformat-security, and it's
> a good idea to make sure we continue to do so (since calls
> that trigger the warning may be security vulnerabilities).
Nice. I had this flag in my config.mak too before switching to
On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
>
> Just printing the command that the user entered is not particularly
> helpful when trying to find the alias that causes the loop.
>
> Print the history of substituted commands to help the user find the
> offending alias. Mark the entrypoint
On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
> + /*
> +* It could be an alias -- this works around the insanity
> * of overriding "git log" with "git show" by having
> * alias.log = show
> */
I think this co
On Fri, Sep 7, 2018 at 7:21 PM Junio C Hamano wrote:
>
> Ben Peart writes:
>
> > On further investigation with the previous patch, I noticed that my test
> > repos didn't contain the cache tree extension in their index. After doing a
> > commit to ensure they existed, I realized that in some inst
On Sat, Sep 8, 2018 at 11:28 AM Hultqvist wrote:
>
> The bash commands are using a git and bash bundle that was installed
> in parallel with gitextensions(a gui for git)
>
> G:\Min enhet> set GIT_TRACE_SETUP=1
> G:\Min enhet> git st
> 10:40:28.881927 trace.c:318 setup: git_dir:
> C:/Us
The bash commands are using a git and bash bundle that was installed
in parallel with gitextensions(a gui for git)
G:\Min enhet> set GIT_TRACE_SETUP=1
G:\Min enhet> git st
10:40:28.881927 trace.c:318 setup: git_dir:
C:/Users/hultqvist/Drive.git
10:40:28.881927 trace.c:319 s
Am 07.09.2018 um 20:19 schrieb Jeff Hostetler via GitGitGadget:
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
compat/mingw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..ef03bbe5d2 100644
--- a/compat/mingw.c
On Thu, Sep 6, 2018 at 9:34 PM, Jeff King wrote:
>
> By the way, I've got funding from GitHub lined up, so we are good on
> that front.
Great, thanks!
On Thu, Sep 6, 2018 at 9:31 PM, Jeff King wrote:
> On Thu, Sep 06, 2018 at 11:51:49AM +0200, Christian Couder wrote:
>
>> Yeah, I think the https://git.github.io/Outreachy-17/ is not actually
>> necessary.
>
> I think it still may be helpful for explaining in further detail things
> like #leftove
On Tue, Sep 04, 2018 at 02:27:20PM -0700, Pratik Karki via GitGitGadget wrote:
> From: Pratik Karki
>
> When running a rebase on a detached HEAD, we currently store the string
> "detached HEAD" in options.head_name. That is a faithful translation of
> the shell script version, and we still kind o
49 matches
Mail list logo
