On Wed, Jun 27, 2018 at 3:24 PM, Derrick Stolee wrote:
> When writing commit-graph files, it can be convenient to ask for all
> reachable commits (starting at the ref set) in the resulting file. This
> is particularly helpful when writing to stdin is complicated, such as a
> future integration
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> RFC 3875 (the CGI specification) explains:
>>
>>The CONTENT_LENGTH variable contains the size of the message-body
>>attached to the request, if any, in decimal number of octets. If no
>>data is attached, then NULL (or unset).
[...]
Jonathan Nieder writes:
> RFC 3875 (the CGI specification) explains:
>
>The CONTENT_LENGTH variable contains the size of the message-body
>attached to the request, if any, in decimal number of octets. If no
>data is attached, then NULL (or unset).
>
> CONTENT_LENGTH = "" |
Max Kirillov wrote:
> On Sun, Sep 09, 2018 at 10:17:48PM -0700, Jonathan Nieder wrote:
>> From: Max Kirillov
>> Subject: http-backend test: make empty CONTENT_LENGTH test more realistic
>
> Thank you, yes, this is what should have left
Oh, tying up this loose end: do you know why the test
Kicking off the reviews: ;-)
Jonathan Nieder wrote:
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -350,10 +350,25 @@ static ssize_t read_request_fixed_len(int fd, ssize_t
> req_len, unsigned char **o
>
> static ssize_t get_content_length(void)
[...]
> + /*
> + *
As discussed in v2.19.0-rc0~45^2~2 (http-backend: respect
CONTENT_LENGTH as specified by rfc3875, 2018-06-10), HTTP servers such
as IIS do not close a CGI script's standard input at the end of a
request, instead expecting CGI scripts to stop reading after
CONTENT_LENGTH bytes. That commit taught
On Mon, Sep 10, 2018 at 5:52 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> >> Of course, even though these are 1/2 and 2/2, only one of them and
> >> not both would apply.
> >
> > Or you could squash them once we reach consensus that both are good.
>
> Ah, sorry, I completely misread
On Mon, Sep 10, 2018 at 07:20:28PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Mon, Sep 10, 2018 at 02:22:21PM -0700, Jonathan Nieder wrote:
>
> >> Thanks. I am wondering if we should go all the way and do
> >>
> >>ssize_t val;
> >>const char *str = getenv("CONTENT_LENGTH");
Jeff King wrote:
> On Mon, Sep 10, 2018 at 02:22:21PM -0700, Jonathan Nieder wrote:
>> Thanks. I am wondering if we should go all the way and do
>>
>> ssize_t val;
>> const char *str = getenv("CONTENT_LENGTH");
>>
>> if (!str || !*str)
>> return 0;
>> if
On Mon, Sep 10, 2018 at 11:53:59PM +0300, Max Kirillov wrote:
> From: Jeff King
> Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero
>
> There is no known case where empty body it used by a server as
> instruction to read until EOF, so there is no need to violate the RFC.
> Make
On Mon, Sep 10, 2018 at 02:22:21PM -0700, Jonathan Nieder wrote:
> Thanks. I am wondering if we should go all the way and do
>
> ssize_t val;
> const char *str = getenv("CONTENT_LENGTH");
>
> if (!str || !*str)
> return 0;
> if (!git_parse_ssize_t(str, ))
Stefan Beller writes:
>> Of course, even though these are 1/2 and 2/2, only one of them and
>> not both would apply.
>
> Or you could squash them once we reach consensus that both are good.
Ah, sorry, I completely misread the first one. I thought that it
was extending the implementation of
On Mon, Sep 10, 2018 at 3:32 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > I separated this from the other series, making it into 2 patches:
> > This first patch adds tracing for string lists and the next patch that
> > removes the unused function from the string list API.
> > That
Stefan Beller writes:
> I separated this from the other series, making it into 2 patches:
> This first patch adds tracing for string lists and the next patch that
> removes the unused function from the string list API.
> That way we can decide on these two patches separately if needed.
Of
Hello,
On 06.09.2018 20:53, Ævar Arnfjörð Bjarmason wrote:
On Thu, Sep 06 2018, Ævar Arnfjörð Bjarmason wrote:
On Thu, Sep 06 2018, SZEDER Gábor wrote:
On Thu, Sep 06, 2018 at 02:26:49PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Thu, Sep 06 2018, SZEDER Gábor wrote:
Several tests failed
Jonathan Nieder writes:
> Josh Steadmon wrote:
>
>> From: Brandon Williams
>>
>> Update the config documentation to note the value `2` as an acceptable
>> value for the protocol.version config.
>>
>> Signed-off-by: Brandon Williams
>> Signed-off-by: Josh Steadmon
>> ---
>>
Johannes Sixt writes:
>> +#define IS_SBS(ch) (((ch) == '/') || ((ch) == '\\'))
I think you already have mingw_is_dir_sep() and its shorter alias
is_dir_sep() available to you.
>> +/*
>> + * Does the pathname map to the local named pipe filesystem?
>> + * That is, does it have a "//./pipe/"
Similar to trace_strbuf or trace_argv_printf, we might want to output
a string list in tracing. Add such a function.
Signed-off-by: Stefan Beller
---
I separated this from the other series, making it into 2 patches:
This first patch adds tracing for string lists and the next patch that
removes
Signed-off-by: Stefan Beller
---
string-list.c | 10 --
string-list.h | 8
2 files changed, 18 deletions(-)
diff --git a/string-list.c b/string-list.c
index 771c4550980..1f6063f2a27 100644
--- a/string-list.c
+++ b/string-list.c
@@ -195,16 +195,6 @@ void
Josh Steadmon wrote:
> From: Brandon Williams
>
> Update the config documentation to note the value `2` as an acceptable
> value for the protocol.version config.
>
> Signed-off-by: Brandon Williams
> Signed-off-by: Josh Steadmon
> ---
> Documentation/config.txt | 2 ++
> 1 file changed, 2
Hi,
Max Kirillov wrote:
> From: Jeff King
> Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero
micronit: s/Treat/treat/
> There is no known case where empty body it used by a server as
> instruction to read until EOF, so there is no need to violate the RFC.
> Make
From: Brandon Williams
Update the config documentation to note the value `2` as an acceptable
value for the protocol.version config.
Signed-off-by: Brandon Williams
Signed-off-by: Josh Steadmon
---
Documentation/config.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Jeff King
Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero
There is no known case where empty body it used by a server as
instruction to read until EOF, so there is no need to violate the RFC.
Make get_content_length() return 0 in this case.
Currently there is no
On Sun, Sep 09, 2018 at 10:17:48PM -0700, Jonathan Nieder wrote:
> From: Max Kirillov
> Subject: http-backend test: make empty CONTENT_LENGTH test more realistic
Thank you, yes, this is what should have left
On Mon, Sep 10, 2018 at 09:55:30AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >>} else {
> >> - options.head_name = xstrdup("detached HEAD");
> >> + free(options.head_name);
> >> + options.head_name = NULL;
> >
> >
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
On 9/10/2018 3:45 PM, Johannes Sixt wrote:
Am 10.09.18 um 19:05 schrieb Jeff Hostetler via GitGitGadget:
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..f87376b26a 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -341,6 +341,19 @@ int mingw_mkdir(const char *path, int mode)
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 =
Am 10.09.18 um 19:05 schrieb Jeff Hostetler via GitGitGadget:
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..f87376b26a 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -341,6 +341,19 @@ int mingw_mkdir(const char *path, int mode)
return ret;
}
+/*
+ * Calling
On 9/10/2018 1:07 PM, Stefan Beller wrote:
On Mon, Sep 10, 2018 at 9:29 AM Ben Peart wrote:
It was reported that
GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all ./t7411-submodule-config.sh
breaks as the fsmonitor data is out of sync with the state of the .gitmodules
file. Update
On Mon, Sep 10, 2018 at 09:19:32PM +0200, SZEDER Gábor wrote:
> > I'd have thought that anybody
> > adding index-specific tracing would do it as GIT_TRACE_INDEX.
>
> Depends on the purpose, I guess. For tracing that is aimed to become
> part of in git, definitely. However, for my own ad-hoc
Stefan Beller writes:
> On Sun, Sep 9, 2018 at 1:54 AM Nguyễn Thái Ngọc Duy wrote:
>>
>> ---
>
> Junio would have to forge your Sign off here?
> (I just realize this holds true for the whole series,
> but it occurred to me in this patch, as I was looking at
> the diff_setup[_done] part on the
Jeff King writes:
>> Either is fine. I am not moving 'next' beyond what is necessary for
>> this release cycle during the pre-release freeze period, and because
>> I thought that Peff was in favor of squashing in the changes to the
>> original when the next cycle starts, I haven't bothered to
On Mon, Sep 10, 2018 at 11:44:54AM -0400, Jeff King wrote:
> On Mon, Sep 10, 2018 at 04:07:14PM +0200, SZEDER Gábor wrote:
>
> > The test 'add -p does not expand argument lists' in
> > 't3701-add-interactive.sh', added in 7288e12cce (add--interactive: do
> > not expand pathspecs with ls-files,
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'"
>
On Sun, Sep 9, 2018 at 1:54 AM Nguyễn Thái Ngọc Duy wrote:
>
> ---
Junio would have to forge your Sign off here?
(I just realize this holds true for the whole series,
but it occurred to me in this patch, as I was looking at
the diff_setup[_done] part on the previous round.
On Sun, Sep 9, 2018 at 1:02 AM Duy Nguyen wrote:
>
> On Tue, Sep 4, 2018 at 9:54 PM Stefan Beller wrote:
> >
> > On Mon, Sep 3, 2018 at 11:03 AM Duy Nguyen wrote:
> > >
> > > On Mon, Aug 27, 2018 at 9:13 PM Stefan Beller wrote:
> > > >
> > > > > -int init_patch_ids(struct patch_ids *ids)
> > >
On Mon, Sep 10, 2018 at 09:53:56AM -0700, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when
> > building my own package of git, but I think this really should be fixed
> > in that branch, either by merging the fix
On Mon, Sep 10, 2018 at 09:37:20AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > But that couldn't have been what older versions were doing, since they
> > never looked at CONTENT_LENGTH at all, and instead always read to EOF.
> > So presumably the original problem wasn't that we tried
"Eckhard Maaß" writes:
> On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote:
>> It is neither but if I have to pick one between the two, it is much
>> closer to the former than the latter. The primary source of this is
>> that we have only *one* pathspec given to the diff machinery,
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
On Sun, Sep 9, 2018 at 1:54 AM Nguyễn Thái Ngọc Duy wrote:
>
> The last patch 24/24 has been merged into individual patches to add
> repo_ prefix and avoid breaking in-flight topics. "repo" argument is
> also moved up in rerere(), diff_setup() and init_revisions().
yay!
So eventually we'd want
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
Jiang Xin writes:
> Hi Junio,
>
> The following changes since commit 2f743933341f27603550fbf383a34dfcfd38:
>
> Git 2.19-rc1 (2018-08-28 12:01:01 -0700)
>
> are available in the Git repository at:
>
> git://github.com/git-l10n/git-po tags/l10n-2.19.0-rnd2
>
> for you to fetch changes up
On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote:
> It is neither but if I have to pick one between the two, it is much
> closer to the former than the latter. The primary source of this is
> that we have only *one* pathspec given to the diff machinery, but in
> order to implement
Jeff King writes:
> Not that I'm totally opposed to your patch, but it's a little sad that
> we have to match the specific text used in GIT_TRACE now (and if they
> ever changed we won't even notice, but rather the test will just become
> a silent noop).
>
> I think it would be nice if we could
Ævar Arnfjörð Bjarmason writes:
> Looking at the git-range-diff manpage though it recommends
> over ... when the topic has been rebased, which is
> usually the case for e.g. a topic that's submitted to git.git (usually
> be the time feedback has been gathered & a re-submission has been made
>
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
> >> Like this (generated using "git revert -m1)?
> >
> > OK. Thanks for taking care of it.
Yes that looks good to me, thanks!
>
> Please don't forget to remove the corresponding release notes entry.
Makes sense, too.
Thanks,
Stefan
On Mon, Sep 10, 2018 at 9:29 AM Ben Peart wrote:
>
> It was reported that
>
>GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all ./t7411-submodule-config.sh
>
> breaks as the fsmonitor data is out of sync with the state of the .gitmodules
> file. Update is_staging_gitmodules_ok() so that it no longer
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
compat/mingw.c| 38 ---
t/t0051-windows-named-pipe.sh | 2 +-
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 858ca14a57..f87376b26a
The recent change mingw O_APPEND change breaks writing to named pipes on
Windows. The first commit adds a new test to confirm the breakage and the
second commit fixes the problem. These could be squashed together or we can
just keep the fix and omit the test if that would be better.
d641097589
From: Jeff Hostetler
Create a test-tool helper to create the server side of
a windows named pipe, wait for a client connection, and
copy data written to the pipe to stdout.
Create t0051 test to route GIT_TRACE output of a command
to a named pipe using the above test-tool helper.
Signed-off-by:
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 9/10/2018 12:42 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
Yeah, this whole thing is a little under-documented for my tastes.
Let's leave it as you have it. I'll re-roll with a fix to route
named pipes to the existing _wopen() code.
OK, I have these two patches in 'next', but
SZEDER Gábor writes:
>> } else {
>> -options.head_name = xstrdup("detached HEAD");
>> +free(options.head_name);
>> +options.head_name = NULL;
>
> Please use FREE_AND_NULL(options.head_name) here.
Good; did
Ævar Arnfjörð Bjarmason writes:
> I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when
> building my own package of git, but I think this really should be fixed
> in that branch, either by merging the fix down or reverting the original
> series out of next, I think just merging
Jeff Hostetler writes:
> Yeah, this whole thing is a little under-documented for my tastes.
> Let's leave it as you have it. I'll re-roll with a fix to route
> named pipes to the existing _wopen() code.
OK, I have these two patches in 'next', but let's postpone it for
now. Windows port will
Jeff King writes:
> But that couldn't have been what older versions were doing, since they
> never looked at CONTENT_LENGTH at all, and instead always read to EOF.
> So presumably the original problem wasn't that we tried to read a body,
> but that the empty string caused git_parse_ssize_t to
It was reported that
GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all ./t7411-submodule-config.sh
breaks as the fsmonitor data is out of sync with the state of the .gitmodules
file. Update is_staging_gitmodules_ok() so that it no longer tells
ie_match_stat() to ignore refreshing the fsmonitor
Jeff King writes:
> Your explanation is correct. To be fair, though, it seems like
> --find-copies-harder is made a lot less useful by the not considering
> the larger set of sources, since that's kind of its point. I'm not sure
> if this behavior actually is intentional, or simply what happens
Hi,
I have the latest git and it includes a nice auto-completion for zsh:
contrib/completion/git-completion.zsh
I’ve been using it happily for.. years I guess, until I ran into a problem
yesterday.
I have a branch with apostrophe, named like: somebody's_business
When I want to switch to that
On 9/6/2018 4:34 PM, Stefan Beller wrote:
It was reported that
GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all ./t7411-submodule-config.sh
breaks as the .gitmodules file is modified and staged after the fsmonitor
considers it clean. Mark the .gitmodules file to be not clean before
staging.
On 9/8/2018 2:31 PM, Johannes Sixt wrote:
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
On Mon, Sep 10, 2018 at 04:07:14PM +0200, SZEDER Gábor wrote:
> The test 'add -p does not expand argument lists' in
> 't3701-add-interactive.sh', added in 7288e12cce (add--interactive: do
> not expand pathspecs with ls-files, 2017-03-14), checks the GIT_TRACE
> of 'git add -p' to ensure that the
> Tighten this 'grep' pattern to only match trace lines that show the
> executed commands.
Looks good, and I think that this is the only such occurrence in t3701
that needs this treatment.
Signed-off-by: Taylor Blau
The test 'add -p does not expand argument lists' in
't3701-add-interactive.sh', added in 7288e12cce (add--interactive: do
not expand pathspecs with ls-files, 2017-03-14), checks the GIT_TRACE
of 'git add -p' to ensure that the name of a tracked file wasn't
passed around as argument to any of the
On Sun, Sep 09, 2018 at 07:19:51PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> And then I turn that into:
> >>
> >> # @{u} because I happen to be on 'master' and it's shorter to type
> >> # than origin/master...
> >> git range-diff @{u} 38b5f0fe72...718fbdedbc
> >
> > I don't
On September 10, 2018 4:09 AM, Sergei Haller wrote:
> my problem is basically the following: my git server (https) requires
> authentication using a clent x509 certificate.
>
> And I have multiple x509 certificates that match the server.
>
> when I access the https server using a browser, the
On Sun, Sep 09, 2018 at 12:04:58PM -0700, Bryan Turner wrote:
> Here, though, you've _explicitly limited_ Git to only the copied file.
> It's not allowed to consider any others, which means it can't "see"
> the source path anymore. As a result, the copy is detected as a
> straight add. Note that
On 9/9/2018 3:28 AM, Sebastian Schuberth wrote:
On 9/7/2018 8:19 PM, Jeff Hostetler via GitGitGadget wrote:
+test_expect_success MINGW 'o_append write to named pipe' '
Shouldn't this be "test_expect_failure" here, and then be changed to
"test_expect_success" by your second patch?
On Sun, Sep 09, 2018 at 10:25:58PM -0700, Jonathan Nieder wrote:
> > --- a/http-backend.c
> > +++ b/http-backend.c
> > @@ -353,8 +353,28 @@ static ssize_t get_content_length(void)
> > ssize_t val = -1;
> > const char *str = getenv("CONTENT_LENGTH");
> >
> > - if (str &&
Sending again without HTML
Den mån 10 sep. 2018 kl 12:28 skrev Hultqvist :
>
> First I need to correct my previous observations.
>
> Today there appeared new set of config files in the root.
> I looked into a few of them and found that their content doesn't match that
> of the repo at "G:/Min
Hi folks,
my problem is basically the following: my git server (https) requires
authentication using a clent x509 certificate.
And I have multiple x509 certificates that match the server.
when I access the https server using a browser, the browser asks which
certificate to use and everything is
74 matches
Mail list logo
