Re: [RFC] dropping support for ancient versions of curl

> On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote: > >> If we declared 7.16.0 as a cutoff, we could unconditionally define >> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs. > > That version came out 11 years ago. Here's what that patch would look > like (on top of my other

Re: [RFC] dropping support for ancient versions of curl

On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote: > If we declared 7.16.0 as a cutoff, we could unconditionally define > USE_CURL_MULTI, which gets rid of quite a few messy ifdefs. That version came out 11 years ago. Here's what that patch would look like (on top of my other one, but

[RFC] dropping support for ancient versions of curl

A nearby thread raised the question of whether we can rely on a version of libcurl that contains a particular feature. The version in question is curl 7.11.1, which came out in March 2004. My feeling is that this is old enough to stop caring about. Which means we can drop some of the #ifdefs that

Re: [PATCH v5] http.postbuffer: allow full range of ssize_t values

On Mon, Apr 03, 2017 at 06:32:10PM -0700, Jonathan Nieder wrote: > David Turner wrote: > > > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the > > buffer size. > > Neat. > > For completeness, it's useful to know this was added in curl 7.11.1, > which is old enough for us to

Re: [PATCH v4 2/4] fsck: force core.checksumindex=1

On Mon, Apr 03, 2017 at 10:31:03PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Mon, Apr 3, 2017 at 8:53 PM, wrote: > > Teach fsck to override core.checksumindex and always verify > > the index checksum when reading the index. > > Sorry to only chime in about this at v4.

Re: [PATCH/RFC] gitperformance: add new documentation about git performance tuning

On Mon, Apr 03, 2017 at 11:57:51PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> +These features can be enabled on git servers, they won't help the > >> +performance of the servers themselves, > > > > Is that true for bitmaps? I thought they reduced CPU usage on > > the server side... > > I'm not

Re: Bug? git submodule update --reference doesn't use the referenced repository

On 04-Apr-17 4:32 AM, Stefan Beller wrote: On Sun, Apr 2, 2017 at 8:13 PM, Maxime Viargues wrote: Hi there, I have been trying to use the --reference option to clone a big repository using a local copy, but I can't manage to make it work using sub-module update. I

Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values

On Mon, Apr 03, 2017 at 05:03:49PM +, David Turner wrote: > > > Unfortunately, in order to push some large repos, the http postbuffer > > > must sometimes exceed two gigabytes. On a 64-bit system, this is OK: > > > we just malloc a larger buffer. > > > > I'm still not sure why a 2GB

Re: [PATCH v5] http.postbuffer: allow full range of ssize_t values

David Turner wrote: > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the > buffer size. Neat. For completeness, it's useful to know this was added in curl 7.11.1, which is old enough for us to be able to count on users having it (in fact it was released >10 years ago). [...]

[PATCH v5] http.postbuffer: allow full range of ssize_t values

Unfortunately, in order to push some large repos, the http postbuffer must sometimes exceed two gigabytes. On a 64-bit system, this is OK: we just malloc a larger buffer. This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the buffer size. Signed-off-by: David Turner

RE: [PATCH v4] http.postbuffer: allow full range of ssize_t values

> -Original Message- > From: Ramsay Jones [mailto:ram...@ramsayjones.plus.com] > Sent: Monday, April 3, 2017 6:24 PM > To: David Turner ; git@vger.kernel.org > Subject: Re: [PATCH v4] http.postbuffer: allow full range of ssize_t values > > > > On 03/04/17

Re: [PATCH v2 4/8] Specify explicitly where we parse timestamps

Hi Torsten, On Mon, 3 Apr 2017, Torsten Bögershausen wrote: > [] > > --- a/git-compat-util.h > > +++ b/git-compat-util.h > > @@ -319,6 +319,8 @@ extern char *gitdirname(char *); > > #define PRIo32 "o" > > #endif > > > > +#define parse_timestamp strtoul > > + > > Would > #define

Re: [PATCH v7 3/5] dir_iterator: add helpers to dir_iterator_advance

On Sun, Apr 2, 2017 at 1:03 PM, Daniel Ferreira wrote: > Create inline helpers to dir_iterator_advance(). Make > dir_iterator_advance()'s code more legible and allow some behavior to > be reusable. > > Signed-off-by: Daniel Ferreira > --- > +static inline

Re: [PATCH v2 1/8] ref-filter: avoid using `unsigned long` for catch-all data type

Hi Torsten, On Mon, 3 Apr 2017, Torsten Bögershausen wrote: > On 02/04/17 21:06, Johannes Schindelin wrote: > > In its `atom_value` struct, the ref-filter source code wants to store > > different values in a field called `ul` (for `unsigned long`), e.g. > > timestamps. > > > > However, as we are

Re: [PATCH/RFC] gitperformance: add new documentation about git performance tuning

Ævar Arnfjörð Bjarmason wrote: > On Mon, Apr 3, 2017 at 11:34 PM, Eric Wong wrote: > > Ævar Arnfjörð Bjarmason wrote: > >> - Should we be covering good practices for your repo going forward to > >>maintain good performance? E.g. don't

Re: [PATCH v7 2/5] remove_subtree(): test removing nested directories

On Sun, Apr 2, 2017 at 1:03 PM, Daniel Ferreira wrote: > Test removing a nested directory when an attempt is made to restore the > index to a state where it does not exist. A similar test could be found > previously in t/t2000-checkout-cache-clash.sh, but it did not check for >

Re: [PATCH v7 1/5] dir_iterator: add tests for dir_iterator API

On Sun, Apr 2, 2017 at 1:03 PM, Daniel Ferreira wrote: > Create t/helper/test-dir-iterator.c, which prints relevant information > about a directory tree iterated over with dir_iterator. > > Create t/t0065-dir-iterator.sh, which tests that dir_iterator does > iterate through a

Re: [PATCH v4] http.postbuffer: allow full range of ssize_t values

On 03/04/17 18:30, David Turner wrote: > Unfortunately, in order to push some large repos, the http postbuffer > must sometimes exceed two gigabytes. On a 64-bit system, this is OK: > we just malloc a larger buffer. > > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the >

Re: [PATCH/RFC] gitperformance: add new documentation about git performance tuning

On Mon, Apr 3, 2017 at 11:34 PM, Eric Wong wrote: > Ævar Arnfjörð Bjarmason wrote: >> Add a new manpage that gives an overview of how to tweak git's >> performance. >> >> There's currently no good single resource for things a git site >> administrator might want

[GSoC][PATCH v5] t2027: avoid using pipes

Whenever a git command is present in the upstream of a pipe, its failure gets masked by piping. Hence we should avoid it for testing the upstream git command. By writing out the output of the git command to a file, we can test the exit codes of both the commands as a failure exit code in any

Re: [PATCH/RFC] gitperformance: add new documentation about git performance tuning

Ævar Arnfjörð Bjarmason wrote: > Add a new manpage that gives an overview of how to tweak git's > performance. > > There's currently no good single resource for things a git site > administrator might want to look into to improve performance for his > site & his users. This

[PATCH/RFC] gitperformance: add new documentation about git performance tuning

Add a new manpage that gives an overview of how to tweak git's performance. There's currently no good single resource for things a git site administrator might want to look into to improve performance for his site & his users. This unfinished documentation aims to be the first thing someone might

Re: [PATCH v4 2/4] fsck: force core.checksumindex=1

On Mon, Apr 3, 2017 at 8:53 PM, wrote: > Teach fsck to override core.checksumindex and always verify > the index checksum when reading the index. Sorry to only chime in about this at v4. I think this patch & the documentation you added for core.checksumindex in 1/4

Re: [GSoC][PATCH v4] t2027: avoid using pipes

On Fri, Mar 24, 2017 at 5:04 AM, Prathamesh Chavan wrote: > Whenever a git command is present in the upstream of a pipe, its failure > gets masked by piping and hence it should be avoided for testing the > upstream git command. By writing out the output of the git command to >

Re: [PATCH v4] http.postbuffer: allow full range of ssize_t values

On 03.04.17 19:30, David Turner wrote: > Unfortunately, in order to push some large repos, the http postbuffer > must sometimes exceed two gigabytes. On a 64-bit system, this is OK: > we just malloc a larger buffer. > > This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the >

[PATCH v4 3/4] t1450-fsck: test core.checksumindex

From: Jeff Hostetler Add test for fsck to force verify the index checksum. Add test to demonstrate that status does ignore the checksum when reading the index. Signed-off-by: Jeff Hostetler --- t/t1450-fsck.sh | 27 +++ 1

[PATCH v4 1/4] read-cache: core.checksumindex

From: Jeff Hostetler Teach git to skip verification of the SHA-1 checksum at the end of the index file in verify_hdr() called from read_index() when the core.checksumIndex configuration variable is set to false. The checksum verification is for detecting disk corruption,

[PATCH v4 0/4] read-cache: call verify_hdr() in a background thread

From: Jeff Hostetler Version 4 of this patch series incorporates the cleanup made by Junio to my 3rd veresion, updates fsck to always verify the checksum, and a new simplified perf test using p0002 as discussed on the mailing list. Version 3 of this

[PATCH v4 4/4] p0002-read-cache: test core.checksumindex

From: Jeff Hostetler Teach t/perf/p0002-read-cache to time read_cache() with and without the index checksum calculation. Signed-off-by: Jeff Hostetler --- t/perf/p0002-read-cache.sh | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-)

[PATCH v4 2/4] fsck: force core.checksumindex=1

From: Jeff Hostetler Teach fsck to override core.checksumindex and always verify the index checksum when reading the index. Signed-off-by: Jeff Hostetler --- builtin/fsck.c | 1 + cache.h| 7 +++ read-cache.c | 20

Re: [PATCH v7 4/5] dir_iterator: refactor state machine model

On Mon, Apr 3, 2017 at 12:36 AM, Michael Haggerty wrote: > As far as I can tell, you got the logic in this complicated big loop > correct on the first try (well, if we ignore v6 :-) ), even as you added > new features. I think that's good evidence that the new structure is >

Re: [PATCH] Fix 'git am' in-body header continuations

This looks good to me. On 04/02/2017 05:49 PM, Linus Torvalds wrote: From: Linus Torvalds Date: Sat, 1 Apr 2017 12:14:39 -0700 Subject: [PATCH] Fix 'git am' in-body header continuations An empty line should stop any pending in-body headers, and start the actual

Re: Bug in "git am" when the body starts with spaces

Thanks, everyone, for looking into this. On 04/01/2017 09:18 PM, Jeff King wrote: On Sat, Apr 01, 2017 at 12:03:44PM -0700, Linus Torvalds wrote: The logic is fairly simple: if we encounter an empty line, and we have pending in-body headers, we flush the pending headers, and mark us as no

[PATCH v4] http.postbuffer: allow full range of ssize_t values

Unfortunately, in order to push some large repos, the http postbuffer must sometimes exceed two gigabytes. On a 64-bit system, this is OK: we just malloc a larger buffer. This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the buffer size. Signed-off-by: David Turner

Re: [PATCH v3 3/4] name-rev: provide debug output

Michael J Gruber writes: > No, I checked not to change the existing behaviour. > > If you look at the comment above that then you see that one of the sides > of the comparison is a non-tag, so we compare 0 to 1 or 2, the boolean > outcome being the same. That one I understand,

RE: [PATCH v3] http.postbuffer: allow full range of ssize_t values

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Saturday, April 1, 2017 2:01 AM > To: David Turner > Cc: git@vger.kernel.org > Subject: Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values > > On Fri, Mar 31, 2017 at

Re: Bug? git submodule update --reference doesn't use the referenced repository

On Sun, Apr 2, 2017 at 8:13 PM, Maxime Viargues wrote: > Hi there, > > I have been trying to use the --reference option to clone a big repository > using a local copy, but I can't manage to make it work using sub-module > update. I believe this is a bug, unless I

Re: [PATCH] pathspec: always honor `PATHSPEC_PREFIX_ORIGIN` flag

On 04/03, Patrick Steinhardt wrote: > Previous to commit 5d8f084a5 (pathspec: simpler logic to prefix original > pathspec elements, 2017-01-04), we were always using the computed > `match` variable to perform pathspec matching whenever > `PATHSPEC_PREFIX_ORIGIN` is set. This is for example useful

RE: How do you script linux GIT client to pass kerberos credential to apache enabled GIT server?

-Original Message- On April 3, 2017 12:04 PM, Ken Edward Wrote: >I have my git repositories behind an apache server configured with kerberos. >Works fine if the user is logged in on their workstation. >Apache gets the kerberos credential, and validates, and then sends the GIT >repo

How do you script linux GIT client to pass kerberos credential to apache enabled GIT server?

Hello, I have my git repositories behind an apache server configured with kerberos. Works fine if the user is logged in on their workstation. Apache gets the kerberos credential, and validates, and then sends the GIT repo being requested. BUT, I want to write a script on linux that will also

[PATCH v2 0/2] name-hash: fix buffer overrun

From: Jeff Hostetler Version 2 of this fix smashes the HT and chmod issues in the test code discussed on the mailing list. The test has also been updated to skip on 1 cpu systems. Fix buffer overrun in handle_range_dir() when the final entry in the

[PATCH v2 2/2] name-hash: fix buffer overrun

From: Kevin Willford Add check for the end of the entries for the thread partition. Add test for lazy init name hash with specific directory structure The lazy init hash name was causing a buffer overflow when the last entry in the index was multiple folder deep with

[PATCH v2 1/2] test-online-cpus: helper to return cpu count

From: Jeff Hostetler Created helper executable to print the value of online_cpus() allowing multi-threaded tests to be skipped when appropriate. Signed-off-by: Jeff Hostetler --- Makefile| 1 + t/helper/.gitignore | 1

Re: Terrible bad performance for it blame --date=iso -C

W dniu 03.04.2017 o 12:56, SZEDER Gábor pisze: > Ulrich Windl wrote: >> In the other case (for the user bored of waiting seeking for some >> entertainment ;-)) a "-v (verbose) option could be useful. Or at the >> very least: If git is expecting that some operation will take (or >> already did

Re: [PATCH v3 3/4] name-rev: provide debug output

Junio C Hamano venit, vidit, dixit 31.03.2017 20:33: > Junio C Hamano writes: > >> Michael J Gruber writes: >> The only case that this change may make a difference I can think of is when you have a tag object pointed at from outside refs/tags

Re: Terrible bad performance for it blame --date=iso -C

> In the other case (for the user bored of waiting seeking for some > entertainment ;-)) a "-v (verbose) option could be useful. Or at the > very least: If git is expecting that some operation will take (or > already did take) a lot of time, give some message explaining why it > is taking a lot

[PATCH] pathspec: always honor `PATHSPEC_PREFIX_ORIGIN` flag

Previous to commit 5d8f084a5 (pathspec: simpler logic to prefix original pathspec elements, 2017-01-04), we were always using the computed `match` variable to perform pathspec matching whenever `PATHSPEC_PREFIX_ORIGIN` is set. This is for example useful when passing the parsed pathspecs to other

Antw: Re: Terrible bad performance for it blame --date=iso -C -C master --

Junio, thanks for explaining! So if there are at least two commits, blame is fast, but with only one commit blame tries hard to find another commit that might have contributed to the one file? I verified that without those "-C" options the result is very quick. In the other case (for the user