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
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 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!
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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
=
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
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
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
>> ---
>
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
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
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
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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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, 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
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 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.
49 matches
Mail list logo
