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

On 04/05, Johannes Schindelin wrote: > Hi Brandon, > > On Tue, 4 Apr 2017, Brandon Williams wrote: > > > I'm all for seeing a patch like this applied. I agree that we can't > > expect the world to be running the most up-to-date version of curl but > > we should be able to select some "oldest"

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

On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin wrote: > Hi Brandon, > > On Tue, 4 Apr 2017, Brandon Williams wrote: > >> I'm all for seeing a patch like this applied. I agree that we can't >> expect the world to be running the most up-to-date version of curl but

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

Hi Brandon, On Tue, 4 Apr 2017, Brandon Williams wrote: > I'm all for seeing a patch like this applied. I agree that we can't > expect the world to be running the most up-to-date version of curl but > we should be able to select some "oldest" version we will support which > can be bumped up

Re: What's cooking in git.git (Mar 2017, #12; Wed, 29)

> * sb/submodule-short-status (2017-03-27) 7 commits > - submodule.c: correctly handle nested submodules in is_submodule_modified > - short status: improve reporting for submodule changes > - submodule.c: stricter checking for submodules in is_submodule_modified > - submodule.c: port

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

On Tue, Apr 4, 2017 at 12:39 AM, Eric Wong wrote: > Æ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

[PATCH v4 3/4] test-strcmp-offset: created test for strcmp_offset

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- Makefile | 1 + t/helper/.gitignore | 1 + t/helper/test-strcmp-offset.c | 64 +++ t/t0065-strcmp-offset.sh | 11

[PATCH v4 0/4] read-cache: speed up add_index_entry

From: Jeff Hostetler Teach add_index_entry_with_check() and has_dir_name() to avoid index lookups if the given path sorts after the last entry in the index. This saves at least 2 binary searches per entry. This improves performance during checkout and read-tree because

[PATCH v4 4/4] read-cache: speed up add_index_entry during checkout

From: Jeff Hostetler Teach add_index_entry_with_check() and has_dir_name() to see if the path of the new item is greater than the last path in the index array before attempting to search for it. During checkout, merge_working_tree() populates the new index in sorted

[PATCH v4 2/4] read-cache: add strcmp_offset function

From: Jeff Hostetler Add strcmp_offset() function to also return the offset of the first change. Signed-off-by: Jeff Hostetler --- cache.h | 1 + read-cache.c | 29 + 2 files changed, 30 insertions(+) diff

[PATCH v4 1/4] p0004-read-tree: perf test to time read-tree

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- t/perf/p0004-read-tree.sh | 84 +++ 1 file changed, 84 insertions(+) create mode 100755 t/perf/p0004-read-tree.sh diff --git

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

On Tue, Apr 04, 2017 at 06:42:23PM +, David Turner wrote: > > What does it look like when it fails? What does GIT_TRACE_CURL look like (or > > GIT_CURL_VERBOSE if your client is older, but remember to sanitize any auth > > lines)? > > Unfortunately, we've already worked around the problem by

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

On Tue, Apr 04, 2017 at 09:13:33AM -0400, Jeff Hostetler wrote: > > But yeah, another way to resolve this is to get rid of the config > > option altogether, or document in git-config.txt that > > core.checksumIndex is obeyed by everything except git-fsck. > > If there's no objections then, I'll

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

On Tue, Apr 04, 2017 at 04:06:46PM +0200, Ævar Arnfjörð Bjarmason wrote: > > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat* > > indefinitely ;-) > > I don't really care about applying this patch, but I wouldn't mind > seeing it applied. > > I just wanted to clarify the

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

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Monday, April 3, 2017 10:02 PM > To: David Turner > Cc: git@vger.kernel.org > Subject: Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values > > On Mon, Apr 03, 2017 at

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

On 4/4/2017 11:18 AM, Ævar Arnfjörð Bjarmason wrote: On Tue, Apr 4, 2017 at 5:07 PM, Jeff Hostetler wrote: On 4/3/2017 5:16 PM, Æ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

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

On 04/04, Ævar Arnfjörð Bjarmason wrote: > On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin > wrote: > > Hi, > > > > On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote: > > > >> I think it's completely fine to include your patch as-is. At some > >> point we need to

Re: [PATCH v2] pathspec: honor `PATHSPEC_PREFIX_ORIGIN` with empty prefix

On 04/04, 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: [PATCH v2 1/2] test-online-cpus: helper to return cpu count

On 03/04/17 16:16, g...@jeffhostetler.com wrote: > 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 > --- >

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

On 04/04/17 00:53, 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 Tue, Apr 4, 2017 at 5:07 PM, Jeff Hostetler wrote: > > On 4/3/2017 5:16 PM, Æ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 >>

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

On 4/3/2017 5:16 PM, Æ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

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

On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin wrote: > Hi, > > On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote: > >> I think it's completely fine to include your patch as-is. At some >> point we need to pass the burden of dealing with these old software >>

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

On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote: > 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. I had a quick look at the 7.11.1 support,

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

On 4/4/2017 4:23 AM, Ævar Arnfjörð Bjarmason wrote: On Tue, Apr 4, 2017 at 4:29 AM, Jeff King wrote: 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

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

Hi, On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote: > I think it's completely fine to include your patch as-is. At some > point we need to pass the burden of dealing with these old software > versions, saying that you should use a <10 year old library isn't > unreasonable. Anyone packaging

Re: Path Too Long fix

I have recently used a program called Long Path Tool & i am so happy with the results that this particular program does. I have more than 50 GB of duplicate files in my computer and i was going crazy with the hard disk space that was being consumed and thanks to the "Long Path Tool" where i don't

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

On Tue, Apr 4, 2017 at 10:33 AM, Jeff King wrote: > On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> On Tue, Apr 4, 2017 at 4:54 AM, Jeff King wrote: >> > My feeling is that this is old enough to stop caring about. Which means >> > we

[PATCH v4 5/5] refs: kill set_worktree_head_symref()

70999e9cec (branch -m: update all per-worktree HEADs - 2016-03-27) added this function in order to update HEADs of all relevant worktrees, when a branch is renamed. It, as a public ref api, kind of breaks abstraction when it uses internal functions of files backend. With the introduction of

[PATCH v4 0/5] Kill manual ref parsing code in worktree.c

v4 adds a new patch, 2/5, which makes the hashmap related functions in refs.c generic, so I could add a new map for worktree ref stores and not abuse submodule hashmap. I mentioned about moving these hashmap back to submodule.c and worktree.c where it can map more than just ref stores (in

[PATCH v4 4/5] worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe()

The manual parsing code is replaced with a call to refs_resolve_ref_unsafe(). The manual parsing code must die because only refs/files-backend.c should do that. Signed-off-by: Nguyễn Thái Ngọc Duy --- branch.c | 3 +- t/helper/test-ref-store.c

[PATCH v4 1/5] environment.c: fix potential segfault by get_git_common_dir()

setup_git_env() must be called before this function to initialize git_common_dir so that it returns a non NULL string. And it must return a non NULL string or segfault can happen because all callers expect so. It does not do so explicitly though and depends on get_git_dir() being called first

[PATCH v4 3/5] refs: introduce get_worktree_ref_store()

files-backend at this point is still aware of the per-repo/worktree separation in refs, so it can handle a linked worktree. Some refs operations are known not working when current files-backend is used in a linked worktree (e.g. reflog). Tests will be written when refs_* functions start to be

[PATCH v4 2/5] refs.c: make submodule ref store hashmap generic

This removes the "submodule" from submodule_hash_entry and other function names. The goal is to reuse the same code and data structure for other ref store types. The first one is worktree ref stores. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 64

Re: [PATCH 2/2] config: resolve symlinks in conditional include's patterns

On Fri, Mar 31, 2017 at 1:38 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> $GIT_DIR returned by get_git_dir() is normalized, with all symlinks >> resolved (see setup_work_tree function). In order to match paths (or >> patterns) against

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

On 2017-04-03 19:04, ken edward wrote: > 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. > >

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

On Mon, Apr 03, 2017 at 09:26:48AM -0700, Brandon Williams wrote: > 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

[PATCH v2] pathspec: honor `PATHSPEC_PREFIX_ORIGIN` with empty prefix

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

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

On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote: > On Tue, Apr 4, 2017 at 4:54 AM, Jeff King wrote: > > My feeling is that this is old enough to stop caring about. Which means > > we can drop some of the #ifdefs that clutter the HTTP code (and there's > > a

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

On Tue, Apr 04, 2017 at 10:23:52AM +0200, Ævar Arnfjörð Bjarmason wrote: > The part that confused my & I found unintuitive is that there's a new > core.WHATEVER config that'll get silently overridden by a specific > command, git-fsck. > > Nothing else I can think of in core.* works like this,

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

On Tue, Apr 4, 2017 at 4:29 AM, Jeff King wrote: > 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

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

On Tue, Apr 4, 2017 at 4:54 AM, Jeff King wrote: > My feeling is that this is old enough to stop caring about. Which means > we can drop some of the #ifdefs that clutter the HTTP code (and there's > a patch at the end of this mail dropping support for everything older > than

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

On Mon, Apr 03, 2017 at 10:42:46AM -0700, Jonathan Tan wrote: > 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

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

On Mon, Apr 03, 2017 at 11:00:09AM -0700, Jonathan Tan wrote: > > diff --git a/t/t4150-am.sh b/t/t4150-am.sh > > index 89a5bacac..44807e218 100755 > > --- a/t/t4150-am.sh > > +++ b/t/t4150-am.sh > > @@ -983,7 +983,9 @@ test_expect_success 'am works with multi-line in-body > > headers' ' > >

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

Signed-off-by: Michael Haggerty --- Daniel, > Although it does make tests harder to understand, if we were to > specify how to iterate with human-readable flags we'd add the getopt() > + flag configuration overhead to this helper program to be able to > handle all cases

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

>>> Jakub Narebski schrieb am 03.04.2017 um 17:16 in Nachricht <0ccc5cab-26b7-4b02-b964-452b61e92...@gmail.com>: > 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