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
Æ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 th
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(&dq, &diff_queued_diff, sizeof(diff_queued_diff));
> > + DIFF_QUEUE_CLE
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 sim
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 th
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 do
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 k
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, wh
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 followin
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.
Signe
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 the
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 function
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 struct
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
> '/.gi
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 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 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 se
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 might
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 becau
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
dest
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 writi
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 mai
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
> throug
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 ne
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 loa
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 noth
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, it
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
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
poin
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 mingw_open_appen
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:
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 (js
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
progres
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 outp
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
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 loa
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 f
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 direct
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
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.
Do
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 suspicion
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" extensi
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 us
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 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)
> >> +
"Stephen P. Smith" writes:
> Fix variable spelling error.
>
> Signed-off-by: Stephen P. Smith
> ---
Thanks ;-)
"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 "co
"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
> wt_sta
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)
>>
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
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
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 to
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 breaki
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
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 cooki
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
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.
>
> ¹ https://github.com/curl/c
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 exa
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 "absorbed"
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 r
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 "A
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 th
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.
>>
>> ¹
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 r
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
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 7, 2018 at 6:48 PM Junio C Hamano wrote:
>
> 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?
>
>
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, followed by "EOIE",
> >> then the h
On Sat, Sep 01 2018, Jeff King wrote:
> On Fri, Aug 31, 2018 at 06:55:58PM -0400, Jeff King wrote:
>
>> On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> > On Tue, Aug 21 2018, Jeff King wrote:
>> >
>> > > +int bitmap_has_sha1_in_uninteresting(struct bitmap_index *bi
71 matches
Mail list logo
