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
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
On Fri, Sep 07, 2018 at 02:49:23AM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>
>> Actually, another reason for the latest issue was that CONTENT_LENGTH
>> is parsed for GET requests at all. It should be parsed only for POST
>> requests, or, rather, only for upoad-pack and receive-pack
Jeff King wrote:
> On Fri, Sep 07, 2018 at 07:22:05PM -0400, Todd Zullinger wrote:
>
>> With curl-7.61.1 cookies are sorted by creation-time¹. Sort the output
>> used in the 'cookies stored in http.cookiefile when http.savecookies
>> set' test before comparing it to the expected cookies.
>>
>>
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
> ---
> Stefan Beller wrote:
>> Jonathan Nieder wrote:
>
>>> I
Hi,
Thomas Braun wrote:
> I'm using git with stash and rebase builtins.
>
> $ git --version --build-options
>
> git version 2.19.0.rc2.windows.1
[...]
> mkdir test
> cd test
> git init
> echo 1 > file
> git add file
> git commit file -m "message"
> git submodule add ./ mysubmod
> git commit -m
Hi,
Max Kirillov wrote:
> According to RFC3875, empty environment variable is equivalent to unset,
> and for CONTENT_LENGTH it should mean zero body to read.
>
> However, unset CONTENT_LENGTH is also used for chunked encoding to indicate
> reading until EOF. At least, the test "large fetch-pack
Subject: Revert "Merge branch 'sb/submodule-core-worktree'"
This reverts commit 7e25437d35a70791b345872af202eabfb3e1a8bc, reversing
changes made to 00624d608cc69bd62801c93e74d1ea7a7ddd6598.
v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after
update, 2018-06-18) assumes an
On Friday, September 7, 2018 3:31:55 PM MST you wrote:
> Junio C Hamano writes:
> The patch is mostly for illustration of the idea.
>
> The result seems to compile and pass the test suite, but I haven't
> carefully thought about what else I may be breaking with this
> mechanical change. For
On Fri, Sep 07, 2018 at 07:22:05PM -0400, Todd Zullinger wrote:
> With curl-7.61.1 cookies are sorted by creation-time¹. Sort the output
> used in the 'cookies stored in http.cookiefile when http.savecookies
> set' test before comparing it to the expected cookies.
>
> ¹
On Fri, Sep 7, 2018 at 6:44 PM Tim Schumacher wrote:
> Introduce a testing suite that is dedicated to aliases.
> For now, check only if nested aliases work and if looping
> aliases are detected successfully.
>
> The looping aliases check for mixed execution is there but
> expected to fail because
With curl-7.61.1 cookies are sorted by creation-time¹. Sort the output
used in the 'cookies stored in http.cookiefile when http.savecookies
set' test before comparing it to the expected cookies.
¹ https://github.com/curl/curl/commit/e2ef8d6fa ("cookies: support
creation-time attribute for
I think we
> should revert e98317508c0 in "master" (for 2.19) and keep making use
> of that 'second try' in "next" (for 2.20).
Actually I'd rather revert the whole topic leading up to
7e25437d35a (Merge branch 'sb/submodule-core-worktree', 2018-07-18)
as the last patch in there doesn't work well
Introduce a testing suite that is dedicated to aliases.
For now, check only if nested aliases work and if looping
aliases are detected successfully.
The looping aliases check for mixed execution is there but
expected to fail because there is no check in place yet.
Signed-off-by: Tim Schumacher
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 of the loop with "<==" and the
last command (which looped back
Aliases can only contain non-alias git commands and their
arguments, not other user-defined aliases. Resolving further
(nested) aliases is prevented by breaking the loop after the
first alias was processed. Git then fails with a command-not-found
error.
Allow resolving nested aliases by not
On Freitag, 7. September 2018 19:08:43 CEST Stefan Beller wrote:
> On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen
wrote:
> > Submodules checked out with older versions of git not longer works in the
> > latest 2.19 releases. A "git submodule update --recursive" command wil
> > fail
> > for
Stefan Beller wrote:
> On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen
> wrote:
>> Submodules checked out with older versions of git not longer works in the
>> latest 2.19 releases. A "git submodule update --recursive" command wil fail
>> for each submodule with a line saying "fatal: could
Junio C Hamano writes:
> "Stephen P. Smith" writes:
>
>> void wt_status_collect(struct wt_status *s)
>> {
>> +struct wt_status_state state;
>> wt_status_collect_changes_worktree(s);
>>
>> if (s->is_initial)
>> @@ -746,6 +752,11 @@ void wt_status_collect(struct wt_status *s)
>>
"Stephen P. Smith" writes:
> void wt_status_collect(struct wt_status *s)
> {
> + struct wt_status_state state;
> wt_status_collect_changes_worktree(s);
>
> if (s->is_initial)
> @@ -746,6 +752,11 @@ void wt_status_collect(struct wt_status *s)
> else
>
"Stephen P. Smith" writes:
> A couple of years ago, during a patch review Junio found that the
> commitable bit as implemented in wt-status.c was broken.
>
> Stephen P. Smith (4):
> Move has_unmerged earlier in the file.
> wt-status: rename commitable to committable
> t7501: add test of
"Stephen P. Smith" writes:
> Fix variable spelling error.
>
> Signed-off-by: Stephen P. Smith
> ---
Thanks ;-)
On Fri, Sep 7, 2018 at 4:29 PM Derrick Stolee wrote:
> On 9/7/2018 1:38 PM, Eric Sunshine wrote:
> > On Fri, Sep 7, 2018 at 11:51 AM Nguyễn Thái Ngọc Duy
> > wrote:
> >> + if (progress)
> >> + display_progress(progress, i);
> >> + if (progress)
> >> +
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 allows uint32_t on any platform, perhaps
On 9/7/2018 1:38 PM, Eric Sunshine wrote:
On Fri, Sep 7, 2018 at 11:51 AM Nguyễn Thái Ngọc Duy wrote:
Refreshing the index is usually very fast, but it can still take a
long time sometimes. Cold cache is one, or something else silly (*).
In this case, it's good to show something to let the
On 9/7/2018 1:55 PM, Junio C Hamano wrote:
Ben Peart writes:
The extension consists of:
- 32-bit offset to the end of the index entries
- 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"
Stefan Beller wrote:
> On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen
> wrote:
>> A "git submodule update --recursive" command wil fail
>> for each submodule with a line saying "fatal: could not open
>> '/.git' for writing> Is a directory.
[...]
> I have the
Hi,
Allan Sandfeld Jensen wrote:
> I discovered it by using Debian testing, and it is shipping the 2.17rcs for
> some reason.
I believe you mean Debian unstable. Debian testing has 2.18.0.
> The example is just an old checkout of qt5.git with submodules,
> it is rather large.
Hi,
Stefan Beller wrote:
> On Wed, Sep 5, 2018 at 12:18 PM Jonathan Nieder wrote:
>> Stefan Beller wrote:
>>> This is the continuation of f2d48994dc1 (submodule.c: submodule_move_head
>>> works with broken submodules, 2017-04-18), which tones down the case of
>>> "broken submodule" in case of a
On Wed, Sep 5, 2018 at 12:18 PM Jonathan Nieder wrote:
>
> Hi,
>
> Stefan Beller wrote:
>
> > This is the continuation of f2d48994dc1 (submodule.c: submodule_move_head
> > works with broken submodules, 2017-04-18), which tones down the case of
> > "broken submodule" in case of a missing git
GitGitGadget botched the CCs when I submitted this.
Replying here to add them.
Sorry,
Jeff
https://github.com/gitgitgadget/gitgitgadget/issues/35
On 9/7/2018 2:19 PM, Jeff Hostetler via GitGitGadget wrote:
The recent change mingw O_APPEND change breaks writing to named pipes on
Windows. The
On 9/7/2018 1: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 instances, the time
to
Before this change the "commit-graph write" command didn't report any
progress. On my machine this command takes more than 10 seconds to
write the graph for linux.git, and around 1m30s on the
2015-04-03-1M-git.git[1] test repository (a test case for a large
monorepository).
Furthermore, since the
Based on feedback on v1, and the "this is yelling at my users through
gc.log" bug I found. Range-diff with v1:
1: e0a09ad641 ! 1: b2dcfa0f55 commit-graph write: add progress output
@@ -5,8 +5,8 @@
Before this change the "commit-graph write" command didn't report any
For the reasons explained in the "commit-graph write: add progress
output" commit leading up to this one, emit progress on "commit-graph
verify". Since e0fd51e1d7 ("fsck: verify commit-graph", 2018-06-27)
"git fsck" has called this command if core.commitGraph=true, but
there's been no progress
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:
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
+++ b/compat/mingw.c
@@ -355,7 +355,7 @@ static int
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
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).
Note that we cannot use the stronger -Wformat-nonliteral, as
there are case where we are clever with passing around
Ben Peart writes:
> The extension consists of:
>
> - 32-bit offset to the end of the index entries
>
> - 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, followed by
On Fri, Sep 7, 2018 at 11:51 AM Nguyễn Thái Ngọc Duy wrote:
> Refreshing the index is usually very fast, but it can still take a
> long time sometimes. Cold cache is one, or something else silly (*).
> In this case, it's good to show something to let the user know "git
> status" is not hanging,
On 9/7/2018 1:15 PM, Jeff King wrote:
On Fri, Sep 07, 2018 at 05:23:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
Hrm, no. I spoke too soon because I was conflating "commit-graph write"
v.s. "gc". For "gc" we're now with this change just e.g. spending 6
seconds on 2015-04-03-1M-git displaying
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 instances, the time
> to load the cache tree exceeded the time to
On Fri, Sep 7, 2018 at 2:53 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > I guess the question is: is this a thing we would want to make available
> > to code to leave in all the time? Or is it just for sticking in
> > temporarily for a quick dump?
> >
> > If the former, then I think it
On Fri, Sep 07, 2018 at 05:23:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Hrm, no. I spoke too soon because I was conflating "commit-graph write"
> v.s. "gc". For "gc" we're now with this change just e.g. spending 6
> seconds on 2015-04-03-1M-git displaying nothing, because we're looping
>
On Friday, September 7, 2018 8:15:43 AM MST Kevin Daudt wrote:
> On Wed, Sep 05, 2018 at 09:17:29PM -0700, Stephen & Linda Smith wrote:
>
> This is the mailsplit command, and should be executed when running `git
> mailsplit`. What does git --exec-dir return?
>
The other night when I ran "git
On Fri, Sep 7, 2018 at 2:53 AM Allan Sandfeld Jensen wrote:
>
> Submodules checked out with older versions of git not longer works in the
> latest 2.19 releases. A "git submodule update --recursive" command wil fail
> for each submodule with a line saying "fatal: could not open
> '/.git' for
Hultqvist writes:
> Considering that the gitdir could be located on a different drive than
> the workdir wouldn't it make more sense to create the temporary files
> in a subdirectory inside the gitdir rather tan in the workdir?
I do not think we intend to create temporary files, whose final
Refreshing the index is usually very fast, but it can still take a
long time sometimes. Cold cache is one, or something else silly (*).
In this case, it's good to show something to let the user know "git
status" is not hanging, it's just busy doing something.
(*) I got called by my colleague
On Fri, Sep 07 2018, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Sep 05 2018, Derrick Stolee wrote:
>
>> On 9/4/2018 6:07 PM, Junio C Hamano wrote:
>>> Ævar Arnfjörð Bjarmason writes:
>>>
With --stdin-packs we don't show any estimation of how much is left to
do. This is because we
On Wed, Sep 05, 2018 at 09:17:29PM -0700, Stephen & Linda Smith wrote:
> I thought I would use "git mailsplit" to split a mbox file (which downloaded
> from public inbox) so that I could attemp to resurrect a patch series for
> from
> a year ago.
>
> The motivation is that I downloaded the
On Freitag, 7. September 2018 17:03:27 CEST Jeff King wrote:
> On Fri, Sep 07, 2018 at 11:52:58AM +0200, Allan Sandfeld Jensen wrote:
> > Submodules checked out with older versions of git not longer works in the
> > latest 2.19 releases. A "git submodule update --recursive" command wil
> > fail
>
On Wed, Sep 05 2018, Derrick Stolee wrote:
> On 9/4/2018 6:07 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> With --stdin-packs we don't show any estimation of how much is left to
>>> do. This is because we might be processing more than one pack. We
>>> could be less lazy
On Fri, Sep 07, 2018 at 11:52:58AM +0200, Allan Sandfeld Jensen wrote:
> Submodules checked out with older versions of git not longer works in the
> latest 2.19 releases. A "git submodule update --recursive" command wil fail
> for each submodule with a line saying "fatal: could not open
>
On Thu, Sep 06, 2018 at 11:32:41PM -0700, Jonathan Nieder wrote:
> > I think Stefan pointed out a "case 4" in the other part of the thread:
> > ones where we really care not just about fast lookup, but actual
> > iteration order.
>
> I had assumed that that was the whole point of this data
On 9/7/2018 12:16 AM, Torsten Bögershausen wrote:
diff --git a/read-cache.c b/read-cache.c
index fcc776aaf0..8537a55750 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1941,20 +1941,212 @@ static void *load_index_extensions(void *_data)
return NULL;
}
+/*
+ * A helper
On 9/7/2018 8:40 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Sep 04 2018, Ævar Arnfjörð Bjarmason wrote:
Before this change the "commit-graph write" command didn't report any
progress. On my machine this command takes more than 10 seconds to
write the graph for linux.git, and around 1m30s on
On 9/6/2018 8:34 PM, Eric Sunshine wrote:
On Wed, Sep 5, 2018 at 10:46 AM Derrick Stolee via GitGitGadget
wrote:
Replace the BUG() statement with a die() statement, now that we
may hit a bad pack-int-id during a 'verify' command on a corrupt
multi-pack-index, and it is covered by a test.
Hi,
(reported at [1] already but reposting here as suggested)
I'm using git with stash and rebase builtins.
$ git --version --build-options
git version 2.19.0.rc2.windows.1
cpu: x86_64
built from commit: 425f414f8e04123eacb5597776d6a8de445a8d8b
sizeof-long: 4
sizeof-size_t: 8
With the
On Tue, Sep 04 2018, Ævar Arnfjörð Bjarmason wrote:
> Before this change the "commit-graph write" command didn't report any
> progress. On my machine this command takes more than 10 seconds to
> write the graph for linux.git, and around 1m30s on the
> 2015-04-03-1M-git.git[1] test repository,
Jeff King writes:
> I guess the question is: is this a thing we would want to make available
> to code to leave in all the time? Or is it just for sticking in
> temporarily for a quick dump?
>
> If the former, then I think it needs the early-return at the least (and
> probably _should_ have the
Jonathan Nieder writes:
> When I think about it this way, I suspect that (B) will provide a
> better experience than (A), so this diff change doesn't seem like a
> step in the wrong direction.
OK, that's fair.
Submodules checked out with older versions of git not longer works in the
latest 2.19 releases. A "git submodule update --recursive" command wil fail
for each submodule with a line saying "fatal: could not open
'/.git' for writing> Is a directory.
I checked the release notes so far, and they
Max Kirillov writes:
> Actually, another reason for the latest issue was that CONTENT_LENGTH
> is parsed for GET requests at all. It should be parsed only for POST
> requests, or, rather, only for upoad-pack and receive-pack requests.
Not really. The layered design of the HTTP protocol means
On Wed, Jul 25, 2018 at 4:53 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > When submitting a revised a patch series, the --range-diff option embeds
> > a range-diff in the cover letter showing changes since the previous
> > version of the patch series. The argument to --range-diff is a
On Wed, Jul 25, 2018 at 5:07 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > + if (cmit_fmt_is_mail(ctx.fmt) && opt->rdiff1) {
> > + struct diff_queue_struct dq;
> > +
> > + memcpy(, _queued_diff, sizeof(diff_queued_diff));
> > +
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Sep 07 2018, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> I don't see any point in generating a sorted list and _then_ making an
>>> auxiliary hashmap. My idea was that if you're using a sorted string-list
>>> for lookup, then you can replace the whole
On Fri, Sep 07 2018, Jonathan Nieder wrote:
> Jeff King wrote:
>
>> I don't see any point in generating a sorted list and _then_ making an
>> auxiliary hashmap. My idea was that if you're using a sorted string-list
>> for lookup, then you can replace the whole thing with a hash (inserting
>> as
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> It seems like various commands are gaining --recurse-submodules options
>> taking different kinds of arguments:
>>
>> - clone takes --recurse-submodules=
>> - fetch takes --recurse-submodules=
>> - after this patch, diff takes
Jeff King wrote:
> I don't see any point in generating a sorted list and _then_ making an
> auxiliary hashmap. My idea was that if you're using a sorted string-list
> for lookup, then you can replace the whole thing with a hash (inserting
> as you go, rather than sorting at the end).
What if I'm
I'm having two types of git repos in separate drives, in this case G:
is a Google Drive File Stream meaning a slow synchronized storage.
First repo:
Workdir: G:\Test1
Gitdir: C:\Test1.git
G:\Test1\.git containing "gitdir: C:\Test1.git"
Second repo:
Workdir: G:\Test2
Gitdir: G:\Test2\.git
In the
71 matches
Mail list logo
