git log --shortstat doesn't respect -c (but --stat does)

This seems inconsistent: $ git log --oneline --stat 91ccfb85176 -c 91ccfb8517 Merge branch 'sb/diff-color-move' diff.c | 28 +++- t/t4015-diff-whitespace.sh | 9 + 2 files changed, 24 insertions(+), 13 deletions(-) d1114d87c7 Merge branch

git push requires a worktree?

I am doing a funny thing where I do git -C .git/modules/morx push fleem:fleem. This is failing in the case where I have a sparse checkout and the worktree directory "morx" (which is where .git/modules/morx/config's core.worktree points) doesn't exist. I don't know why git push cares about the

Re: Implementing reftable in Git

ly. > And since it's too expensive to run the whole test suite with both > reference storage schemes, it seems to me that the reference storage > scheme that is used while running the scheme-neutral tests should be > easy to choose at runtime. I ran the whole suite with both schemes duri

Re: [PATCH 2/5] refs.c: do not die if locking fails in `write_pseudoref()`

On May 6, 2018 9:56:31 AM MDT, "Martin Ågren" <martin.ag...@gmail.com> wrote: >On 6 May 2018 at 17:48, David Turner <nova...@novalis.org> wrote: >> On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote: >>> While at it, make the lock non-static. > &

Re: [PATCH 3/5] refs.c: drop dead code checking lock status in `delete_pseudoref()`

Same concern here about staticness. On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote: > After taking the lock we check whether we got it and die otherwise. > But > since we take the lock using `LOCK_DIE_ON_ERROR`, we would already > have > died. > > Unlike in the previous patch, this

Re: [PATCH 2/5] refs.c: do not die if locking fails in `write_pseudoref()`

Re making the lock static, I wonder about the following case: if (read_ref(pseudoref, _old_oid)) die("could not read ref '%s'", pseudoref); I think this calls exit(), and then atexit tries to clean up the lock files. But since lock is no longer static,

Re: [PATCH] refs: handle null-oid for pseudorefs

LGTM. (This is the current best address to reach me, but do not expect fast responses over the next few days as I'm out of town) On Sun, 2018-05-06 at 15:35 +0200, Martin Ågren wrote: > According to the documentation on `git update-ref`, it is possible to > "specify 40 '0' or an empty string

Re: [PATCH v1] name-hash: properly fold directory names in adjust_dirname_case()

On Wed, 2018-02-07 at 19:41 -0500, Ben Peart wrote: > Correct the pointer arithmetic in adjust_dirname_case() so that it > calls > find_dir_entry() with the correct string length. Previously passing > in > "dir1/foo" would pass a length of 6 instead of the correct 4. This > resulted in >

Re: submodule modify/delete wrong message

On Mon, 2017-12-11 at 12:27 -0800, Stefan Beller wrote: > On Mon, Dec 4, 2017 at 1:39 PM, David Turner <nova...@novalis.org> > wrote: > > When merging with a submodule modify/delete conflict (i.e. I've > > deleted > > the submodule, and I'm merging in a branch t

submodule modify/delete wrong message

When merging with a submodule modify/delete conflict (i.e. I've deleted the submodule, and I'm merging in a branch that modified it), git lies about what it is doing: "CONFLICT (modify/delete): submodule deleted in HEAD and modified in submodules. Version submodules of submodule left in tree at

Re: git reset of addition of a submodule?

On Thu, 2017-11-30 at 12:05 -0500, David Turner wrote: > git submodule add https://my-git-repo blort > git commit -m 'add a submodule' > git reset HEAD^ blort > > The reset deletes the gitlink, but does not delete the entry in > .gitmodules.  On one hand, this is exactly w

git reset of addition of a submodule?

git submodule add https://my-git-repo blort git commit -m 'add a submodule' git reset HEAD^ blort The reset deletes the gitlink, but does not delete the entry in .gitmodules. On one hand, this is exactly what the user asked for -- they wanted the path 'blort' to be changed in the index, and

RE: [PATCH v7 06/12] ls-files: Add support in ls-files to display the fsmonitor valid bit

> -Original Message- > From: Ben Peart [mailto:peart...@gmail.com] > Sent: Tuesday, September 19, 2017 4:45 PM > To: David Turner <david.tur...@twosigma.com>; 'Ben Peart' > <benpe...@microsoft.com> > Cc: ava...@gmail.com; christian.cou...@gmail.co

RE: [PATCH v7 06/12] ls-files: Add support in ls-files to display the fsmonitor valid bit

> -Original Message- > From: Ben Peart [mailto:benpe...@microsoft.com] > Sent: Tuesday, September 19, 2017 3:28 PM > To: benpe...@microsoft.com > Cc: David Turner <david.tur...@twosigma.com>; ava...@gmail.com; > christian.cou...@gmail.com; git@vger.kerne

RE: [PATCH v6 10/12] fsmonitor: add test cases for fsmonitor extension

I think my comment here might have gotten lost, and I don't want it to because it's something I'm really worried about: > -Original Message- > From: David Turner > Sent: Friday, September 15, 2017 6:00 PM > To: 'Ben Peart' <benpe...@microsoft.com> > Cc: ava...@gma

RE: [PATCH v6 04/12] fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

> -Original Message- > From: Ben Peart [mailto:peart...@gmail.com] > Sent: Monday, September 18, 2017 9:07 AM > To: David Turner <david.tur...@twosigma.com>; 'Ben Peart' > <benpe...@microsoft.com> > Cc: ava...@gmail.com; christian.cou...@gmail.com; git@vger.k

RE: [PATCH v6 10/12] fsmonitor: add test cases for fsmonitor extension

> -Original Message- > +dirty_repo () { > + : >untracked && > + : >dir1/untracked && > + : >dir2/untracked && > + echo 1 >modified && > + echo 2 >dir1/modified && > + echo 3 >dir2/modified && > + echo 4 >new && > + echo 5 >dir1/new && > + echo 6

RE: [PATCH v6 12/12] fsmonitor: add a performance test

> -Original Message- > + # Choose integration script based on existance of Watchman. Spelling: existence

RE: [PATCH v6 04/12] fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

> -Original Message- > From: Ben Peart [mailto:benpe...@microsoft.com] > Sent: Friday, September 15, 2017 3:21 PM > To: benpe...@microsoft.com > Cc: David Turner <david.tur...@twosigma.com>; ava...@gmail.com; > christian.cou...@gmail.com; git@vger.kerne

RE: [PATCH v6 06/12] ls-files: Add support in ls-files to display the fsmonitor valid bit

> -Original Message- > From: Ben Peart [mailto:benpe...@microsoft.com] > Sent: Friday, September 15, 2017 3:21 PM > To: benpe...@microsoft.com > Cc: David Turner <david.tur...@twosigma.com>; ava...@gmail.com; > christian.cou...@gmail.com; git@vger.kerne

RE: [PATCH v6 05/12] fsmonitor: add documentation for the fsmonitor extension.

> -Original Message- > From: Ben Peart [mailto:benpe...@microsoft.com] > Sent: Friday, September 15, 2017 3:21 PM > To: benpe...@microsoft.com > Cc: David Turner <david.tur...@twosigma.com>; ava...@gmail.com; > christian.cou...@gmail.com; git@vger.kerne

RE: reftable [v5]: new ref storage format

> -Original Message- > From: Howard Chu [mailto:h...@symas.com] > Sent: Monday, August 14, 2017 8:31 AM > To: spea...@spearce.org > Cc: David Turner <david.tur...@twosigma.com>; ava...@gmail.com; > ben.a...@acegi.com.au; dborow...@google.com; git@vger.kernel.org; &

RE: reftable [v5]: new ref storage format

> -Original Message- > From: Shawn Pearce [mailto:spea...@spearce.org] > In git-core, I'm worried about the caveats related to locking. Git tries to > work > nicely on NFS, and it seems LMDB wouldn't. Git also runs fine on a read-only > filesystem, and LMDB gets a little weird about that.

git-fast-export doesn't support mergetag header

It looks to me like git-fast-export doesn't export the mergetag header on a commit. Is this intentional, or an oversight?

RE: [PATCH v5 7/7] fsmonitor: add a performance test

> -Original Message- > From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C > Hamano > Sent: Friday, July 7, 2017 2:35 PM > To: Ben Peart <peart...@gmail.com> > Cc: git@vger.kernel.org; benpe...@microsoft.com; pclo...@gmail.com; > johannes.schi

bug? fetching from empty unnamed remote repos

$ git init empty-1 $ git init empty-2 $ cd empty-1 $ git fetch ../empty-2 fatal: Couldn't find remote ref HEAD fatal: The remote end hung up unexpectedly But: $ git init empty-1 $ git init empty-2 $ cd empty-1 $ git remote add other ../empty-2 $ git fetch other # this works I haven't spent a

RE: [WIP/PATCH 7/6] perf: add a performance test for core.fsmonitor

nel.org > Cc: Junio C Hamano <gits...@pobox.com>; Ben Peart > <peart...@gmail.com>; Nguyễn Thái Ngọc Duy <pclo...@gmail.com>; > Johannes Schindelin <johannes.schinde...@gmx.de>; David Turner > <david.tur...@twosigma.com>; Jeff King <p...@peff.net>; Ch

RE: [PATCH 0/1] Preserve the untracked cache across checkout, reset --hard, etc

> -Original Message- > From: Ben Peart [mailto:peart...@gmail.com] > Sent: Thursday, May 18, 2017 12:58 PM > To: Junio C Hamano <gits...@pobox.com>; David Turner > <david.tur...@twosigma.com> > Cc: 'Christian Couder' <christian.cou...@gmail.com>; Joh

RE: [PATCH v1 2/5] Teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

> -Original Message- > From: Ben Peart [mailto:peart...@gmail.com] > Sent: Monday, May 15, 2017 3:14 PM > To: git@vger.kernel.org > Cc: gits...@pobox.com; benpe...@microsoft.com; pclo...@gmail.com; > johannes.schinde...@gmx.de; David Turner <david.tur...@twosigma.

RE: [PATCH v1 5/5] Add a sample query-fsmonitor hook script that integrates with the cross platform Watchman file watching service.

> -Original Message- > From: Ben Peart [mailto:peart...@gmail.com] > Sent: Monday, May 15, 2017 3:14 PM > To: git@vger.kernel.org > Cc: gits...@pobox.com; benpe...@microsoft.com; pclo...@gmail.com; > johannes.schinde...@gmx.de; David Turner <david.tur...@twosigma.

RE: [PATCH 0/1] Preserve the untracked cache across checkout, reset --hard, etc

, May 8, 2017 6:12 AM > To: Johannes Schindelin <johannes.schinde...@gmx.de> > Cc: git <git@vger.kernel.org>; Junio C Hamano <gits...@pobox.com>; Nguyễn > Thái Ngọc Duy <pclo...@gmail.com>; Ben Peart <benpe...@microsoft.com>; > David Turner <da

RE: [PATCH] Increase core.packedGitLimit

> -Original Message- > From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de] > Sent: Thursday, April 20, 2017 5:58 PM > To: Jeff King <p...@peff.net> > Cc: David Turner <david.tur...@twosigma.com>; git@vger.kernel.org > Subject: Re: [PATCH] Increa

[PATCH] Increase core.packedGitLimit

this large any time soon, so this should prevent the failure. Helped-by: Jeff King <p...@peff.net> Signed-off-by: David Turner <dtur...@twosigma.com> --- git-compat-util.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-compat-util.h b/git-compat-util.h index 8a4a3f85e7

RE: [PATCH] repack: respect gc.pid lock

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Tuesday, April 18, 2017 1:50 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com > Subject:

RE: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

> I had another look at this last night and cooked up the following patch. > Might > have gone overboard with it.. > > -- >8 -- > Subject: [PATCH] gc: support arbitrary hostnames and pids in > lock_repo_for_gc() > > git gc writes its pid and hostname into a pidfile to prevent concurrent >

RE: [PATCH v3 2/2] xgethostname: handle long hostnames

> -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, April 18, 2017 10:51 PM > To: Jonathan Nieder <jrnie...@gmail.com> > Cc: David Turner <david.tur...@twosigma.com>; git@vger.kernel.org; > l@web.de > Subject: Re: [P

[PATCH v3 2/2] xgethostname: handle long hostnames

-by: David Turner <dtur...@twosigma.com> --- builtin/gc.c | 2 +- builtin/receive-pack.c | 2 +- fetch-pack.c | 2 +- git-compat-util.h | 2 ++ ident.c| 2 +- wrapper.c | 13 + 6 files changed, 19 insertions(+), 4 del

[PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

From: René Scharfe <l@web.de> POSIX limits the length of host names to HOST_NAME_MAX. Export the fallback definition from daemon.c and use this constant to make all buffers used with gethostname(2) big enough for any possible result and a terminating NUL. Inspired-by: David Turner

[PATCH v3 0/2] gethostbyname fixes

. David Turner (1): xgethostname: handle long hostnames René Scharfe (1): use HOST_NAME_MAX to size buffers for gethostname(2) builtin/gc.c | 12 builtin/receive-pack.c | 4 ++-- daemon.c | 4 fetch-pack.c | 4 ++-- git-compat-util.h

RE: [PATCH v2] xgethostname: handle long hostnames

> -Original Message- > From: René Scharfe [mailto:l@web.de] > Sent: Tuesday, April 18, 2017 12:08 PM > To: Junio C Hamano <gits...@pobox.com>; David Turner ... > >> Of course, my_host is sized to HOST_NAME_MAX + 1 and we are comparing > >> it wit

RE: [PATCH] repack: respect gc.pid lock

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Tuesday, April 18, 2017 1:20 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com >

RE: [PATCH] repack: respect gc.pid lock

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Monday, April 17, 2017 11:42 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com > Subject:

RE: [PATCH] repack: respect gc.pid lock

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Monday, April 17, 2017 11:42 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com > Subject:

RE: [PATCH] repack: respect gc.pid lock

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, April 14, 2017 3:34 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com > Subject:

[PATCH v2] xgethostname: handle long hostnames

a consistent buffer size when calling xgethostname. We use HOST_NAME_MAX + 1. When this is unavailable, we fall back to 256, a decision we previously made in daemon.c, but which we now move to git-compat-util.h so that it can be used everywhere. Signed-off-by: David Turner <dtur...@twosigma.

RE: [PATCH] xgethostname: handle long hostnames

> -Original Message- > From: Jonathan Nieder [mailto:jrnie...@gmail.com] > Sent: Thursday, April 13, 2017 6:05 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org > Subject: Re: [PATCH] xgethostname: handle long hostnames > &g

[PATCH] repack: respect gc.pid lock

ock itself. Martin Fick suggested just moving the lock into git repack, but this would leave parts of git gc (e.g. git prune) protected by only local locks. I worried that a prune (part of git gc) concurrent with a repack could confuse the repack, so I decided to go with this solution. Signed-off

[PATCH] xgethostname: handle long hostnames

-by: David Turner <dtur...@twosigma.com> --- builtin/gc.c | 2 +- builtin/receive-pack.c | 2 +- fetch-pack.c | 2 +- git-compat-util.h | 2 ++ ident.c| 2 +- wrapper.c | 13 + 6 files changed, 19 insertions(+), 4 del

Re: Simultaneous gc and repack

On Thu, 2017-04-13 at 12:36 -0600, Martin Fick wrote: > On Thursday, April 13, 2017 02:28:07 PM David Turner wrote: > > On Thu, 2017-04-13 at 12:08 -0600, Martin Fick wrote: > > > On Thursday, April 13, 2017 11:03:14 AM Jacob Keller  > > wrote: > > > > On

Re: Simultaneous gc and repack

On Thu, 2017-04-13 at 12:08 -0600, Martin Fick wrote: > On Thursday, April 13, 2017 11:03:14 AM Jacob Keller wrote: > > On Thu, Apr 13, 2017 at 10:31 AM, David Turner  > > <nova...@novalis.org> wrote: > > > Git gc locks the repository (using a gc.pid file) so

Simultaneous gc and repack

Git gc locks the repository (using a gc.pid file) so that other gcs don't run concurrently. But git repack doesn't respect this lock, so it's possible to have a repack running at the same time as a gc. This makes the gc sad when its packs are deleted out from under it with: "fatal:

RE: [PATCHv2.1] t6500: wait for detached auto gc at the end of the test script

Thanks for fixing this! > -Original Message- > From: SZEDER Gábor [mailto:szeder@gmail.com] > Sent: Thursday, April 13, 2017 6:32 AM > To: Junio C Hamano <gits...@pobox.com> > Cc: Jeff King <p...@peff.net>; Johannes Sixt <j...@kdbg.org>; David Turner &

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

size. Signed-off-by: David Turner <dtur...@twosigma.com> --- cache.h | 1 + config.c | 17 + http.c| 6 -- http.h| 2 +- remote-curl.c | 12 +--- 5 files changed, 32 insertions(+), 6 deletions(-) diff --git a/cache.h b/cache.h

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 <david.tur...@twosigma.com> > Cc: git@vger.kernel.org > Subject: Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values > >

[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 <d

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 <david.tur...@twosigma.com>; git@vger.kernel.org > Subject: Re: [PATCH v4] http.postbuffer: allow full range of ssize_t values >

[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 <d

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 <david.tur...@twosigma.com> > Cc: git@vger.kernel.org > Subject: Re: [PATCH v3] http.postbuffer: allow full range of ssize_t values > >

[PATCH v3] 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. Signed-off-by: David Turner <dtur...@twosigma.com> --- This version fixes the definition of git_parse_ssize_t to retu

RE: [PATCH] http.postbuffer: make a size_t

> -Original Message- > From: Torsten Bögershausen [mailto:tbo...@web.de] > Sent: Friday, March 31, 2017 12:22 AM > To: David Turner <david.tur...@twosigma.com>; git@vger.kernel.org > Subject: Re: [PATCH] http.postbuffer: make a size_t > > > > On 3

[PATCH v2] 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. Signed-off-by: David Turner <dtur...@twosigma.com> --- cache.h | 1 + config.c | 17 + http.c

RE: [PATCH] http.postbuffer: make a size_t

GitLab. I can't speak to our particular configuration of it -- but if you have a specific question about what the config is, I can ask our gitlab admins. > -Original Message- > From: Shawn Pearce [mailto:spea...@spearce.org] > Sent: Thursday, March 30, 2017 4:42 PM > To:

[PATCH] http.postbuffer: make a size_t

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. Signed-off-by: David Turner <dtur...@twosigma.com> --- cache.h | 1 + config.c | 17 + http.c | 2

Re: bug?: git reset --mixed ignores deinitialized submodules

On Mon, 2017-03-13 at 14:19 -0700, Stefan Beller wrote: > > > The change is not really lost, as you can get it via > > > > > > git checkout HEAD@{1} > > > git submodule update --init > > > > Sure, the commit isn't lost entirely.  But a mixed reset is often > > used > > to mean "go back

Re: bug?: git reset --mixed ignores deinitialized submodules

On Mon, 2017-03-13 at 10:51 -0700, Stefan Beller wrote: > On Fri, Mar 10, 2017 at 1:06 PM, David Turner <nova...@novalis.org> > wrote: > > Git reset --mixed ignores submodules which are not > > initialized.  I've > > attached a demo script. > > > > O

bug?: git reset --mixed ignores deinitialized submodules

Git reset --mixed ignores submodules which are not initialized. I've attached a demo script.   On one hand, this matches the documentation ("Resets the index but not the working tree"). But on the other hand, it kind of doesn't: "(i.e., the changed files are preserved but not marked for

RE: [PATCH 2/2] http: add an "auto" mode for http.emptyauth

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Thursday, February 23, 2017 2:44 PM > To: David Turner <david.tur...@twosigma.com> > Cc: Junio C Hamano <gits...@pobox.com>; git@vger.kernel.org; > sand...@crustytoothpaste.net; Johannes

RE: [PATCH 2/2] http: add an "auto" mode for http.emptyauth

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Wednesday, February 22, 2017 8:38 PM > To: David Turner <david.tur...@twosigma.com> > Cc: Junio C Hamano <gits...@pobox.com>; git@vger.kernel.org; > sand...@crustytoothpaste.net; Johannes

RE: [PATCH 2/2] http: add an "auto" mode for http.emptyauth

I don't know enough about how libcurl handles authentication to know whether these patches are a good idea, but I have a minor comment anyway. > -Original Message- > From: Jeff King [mailto:p...@peff.net] > +static int curl_empty_auth_enabled(void) { > + if (curl_empty_auth < 0) { >

RE: [PATCH] http(s): automatically try NTLM authentication first

> -Original Message- > From: brian m. carlson [mailto:sand...@crustytoothpaste.net] > > This is SPNEGO. It will work with NTLM as well as Kerberos. > > Browsers usually disable this feature by default, as it basically will > attempt to > authenticate to any site that sends a 401. For

RE: [PATCH] http(s): automatically try NTLM authentication first

> -Original Message- > From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C > Hamano > Sent: Wednesday, February 22, 2017 3:20 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; sand...@crustytoothpaste.net; Johannes Schind

[PATCH] http(s): automatically try NTLM authentication first

y hard to explain to users) obsolete. This fixes https://github.com/git-for-windows/git/issues/987 Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> Signed-off-by: David Turner <dtur...@twosigma.com> --- This has been in git for Windows for a few months (without the conf

Re: [PATCH v2 0/9] Store submodules in a hash, not a linked list

On Fri, 2017-02-10 at 12:16 +0100, Michael Haggerty wrote: > This is v2 of the patch series, considerably reorganized but not that > different codewise. Thanks to Stefan, Junio, and Peff for their > feedback about v1 [1]. I think I have addressed all of your comments. LGTM.

RE: [PATCH v5] gc: ignore old gc.log files

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, February 10, 2017 4:15 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; pclo...@gmail.com; Junio C Hamano > <gits...@pobox.com> > Subject: Re: [PATC

[PATCH v6] gc: ignore old gc.log files

s too dumb to try again. Signed-off-by: David Turner <dtur...@twosigma.com> Helped-by: Jeff King <p...@peff.net> Signed-off-by: Junio C Hamano <gits...@pobox.com> --- Documentation/config.txt | 6 + builtin/gc.c | 57 +++

RE: [PATCH v3] gc: ignore old gc.log files

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, February 10, 2017 3:09 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; pclo...@gmail.com > Subject: Re: [PATCH v3] gc: ignore old gc.log files > >

[PATCH v5] gc: ignore old gc.log files

s too dumb to try again. Signed-off-by: David Turner <dtur...@twosigma.com> Helped-by: Jeff King <p...@peff.net> Signed-off-by: Junio C Hamano <gits...@pobox.com> --- Documentation/config.txt | 6 + builtin/gc.c | 59 +++

[PATCH v4] gc: ignore old gc.log files

, if necessary, at least once per day. And operators who find a need for more-frequent gcs can adjust gc.logExpiry to meet their needs. Signed-off-by: David Turner <dtur...@twosigma.com> Helped-by: Jeff King <p...@peff.net> --- Documentation/config.txt | 6 builtin/gc.c

[PATCH v3] gc: ignore old gc.log files

will get cleaned up, if necessary, at least once per day. And operators who find a need for more-frequent gcs can adjust gc.logExpiry to meet their needs. Signed-off-by: David Turner <dtur...@twosigma.com> Helped-by: Jeff King <p...@peff.net> --- Documentation/config.txt | 6

[PATCH v2] gc: ignore old gc.log files

where it refuses to do any maintenance, just because at some point some piece of the maintenance didn't make progress. That might still happen (e.g. because the repo is corrupt), but at the very least it won't be because Git is too dumb to try again. Signed-off-by: David Turner <dtur...@twosigma.

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, 2017-02-08 at 09:44 -0800, Junio C Hamano wrote: > Duy Nguyen writes: > > > On second thought, perhaps gc.autoDetach should default to false if > > there's no tty, since its main point it to stop breaking interactive > > usage. That would make the server side happy (no

[PATCH] gc: ignore old gc.log files

happen (e.g. because the repo is corrupt), but at the very least it won't be because Git is too dumb to try again. Signed-off-by: David Turner <dtur...@twosigma.com> Helped-by: Jeff King <p...@peff.net> --- Documentation/config.txt | 5 + builtin/gc.c | 15

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, 2017-02-08 at 14:08 -0500, Jeff King wrote: > On Wed, Feb 08, 2017 at 02:05:42PM -0500, David Turner wrote: > > > On Wed, 2017-02-08 at 09:44 -0800, Junio C Hamano wrote: > > > Duy Nguyen <pclo...@gmail.com> writes: > > > > > > > On seco

Re: "disabling bitmap writing, as some objects are not being packed"?

On Wed, 2017-02-08 at 13:45 +0700, Duy Nguyen wrote: > On Wed, Feb 8, 2017 at 8:03 AM, David Turner <nova...@novalis.org> wrote: > > On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: > >> And we can't grep for fatal errors anyway. The problem that led to >

Re: "disabling bitmap writing, as some objects are not being packed"?

On Sat, 2016-12-17 at 14:50 +0700, Duy Nguyen wrote: > And we can't grep for fatal errors anyway. The problem that led to > 329e6e8794 was this line > > warning: There are too many unreachable loose objects; run 'git > prune' to remove them. > > which is not fatal. So, speaking of that

Re: git cat-file on a submodule

On Wed, 2017-01-11 at 07:53 -0500, Jeff King wrote: > On Tue, Jan 10, 2017 at 07:11:40PM -0500, David Turner wrote: > > > Why does git cat-file -t $sha:foo, where foo is a submodule, not work? > > Because "cat-file" is about inspecting items in the object database, a

git cat-file on a submodule

Why does git cat-file -t $sha:foo, where foo is a submodule, not work? git rev-parse $sha:foo works. By "why", I mean "would anyone complain if I fixed it?" FWIW, I think -p should just return the submodule's sha.

Re: [PATCH] submodule update --init: displays correct path from submodule

(for the test) Signed-off-by: David Turner <dtur...@twosigma.com> TIL: super-prefix! On Fri, 2017-01-06 at 16:19 -0800, Stefan Beller wrote: > In the submodule helper we did not correctly handled the display path > for initializing submodules when both the submodule is inside a &g

minor bug: git submodule update --init from a subdir shows wrong path

I believe (from bisection) that this was introduced in the transition to C at 3604242f080. I've attached a repro (against master). At the time the bug was introduced, the output in question went to stdout instead of stderr, so the attached test case will not quite work on the older version. But

[PATCH v5 2/2] repack: die on incremental + write-bitmap-index

The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner <dtur...@twosigma.com> --- builtin/repack.c| 9 + t/t5310-pack-bitmaps.sh | 8 +++- 2 files changed, 12 insertions(+), 5 del

[PATCH v5 1/2] auto gc: don't write bitmaps for incremental repacks

. This warning was making its way into gc.log. When the gc.log was present, future auto gc runs would refuse to run. Patch by Jeff King. Bug report, test, and commit message by David Turner. Signed-off-by: David Turner <dtur...@twosigma.com> Signed-off-by: Jeff King <p...@peff.net>

[PATCH v5 0/2] repack (oops)

This version addresses Johannes Sixt's comments on v4. Also, I messed up the rebase on v4. David Turner (2): auto gc: don't write bitmaps for incremental repacks repack: die on incremental + write-bitmap-index builtin/gc.c| 9 - builtin/repack.c| 9

[PATCH v4 1/2] auto gc: don't write bitmaps for incremental repacks

. This warning was making its way into gc.log. When the gc.log was present, future auto gc runs would refuse to run. Patch by Jeff King. Bug report, test, and commit message by David Turner. Signed-off-by: David Turner <dtur...@twosigma.com> Signed-off-by: Jeff King <p...@peff.net>

[PATCH v4 2/2] repack: die on incremental + write-bitmap-index

The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner <dtur...@twosigma.com> --- builtin/repack.c| 9 + t/t5310-pack-bitmaps.sh | 8 +++- t/t6500-gc.sh | 8 3

[PATCH v3 0/2] pack bitmaps and incremental packing

Cleaned up the first patch's test code. Decided to remove the unnecessary checks from the second patch. David Turner (2): auto gc: don't write bitmaps for incremental repacks repack: die on incremental + write-bitmap-index builtin/gc.c| 9 - builtin/repack.c| 9

[PATCH v3 2/2] repack: die on incremental + write-bitmap-index

The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner <dtur...@twosigma.com> --- builtin/repack.c| 9 + t/t5310-pack-bitmaps.sh | 8 +++- 2 files changed, 12 insertions(+), 5 del

[PATCH v3 1/2] auto gc: don't write bitmaps for incremental repacks

. This warning was making its way into gc.log. When the gc.log was present, future auto gc runs would refuse to run. Patch by Jeff King. Bug report, test, and commit message by David Turner. Signed-off-by: David Turner <dtur...@twosigma.com> Signed-off-by: Jeff King <p...@peff.net>

[PATCH v2 1/2] auto gc: don't write bitmaps for incremental repacks

. This warning was making its way into gc.log. When the gc.log was present, future auto gc runs would refuse to run. Patch by Jeff King. Bug report, test, and commit message by David Turner. Signed-off-by: David Turner <dtur...@twosigma.com> Signed-off-by: Jeff King <p...@peff.net>

[PATCH v2 2/2] repack: die on incremental + write-bitmap-index

The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner <dtur...@twosigma.com> --- builtin/repack.c| 9 + t/t5310-pack-bitmaps.sh | 5 +++-- 2 files changed, 12 insertions(+), 2 del

RE: [PATCHv4 0/5] git-rm absorbs submodule git directory before deletion

cember 19, 2016 6:28 PM > To: gits...@pobox.com > Cc: git@vger.kernel.org; bmw...@google.com; sand...@crustytoothpaste.net; > David Turner; Stefan Beller > Subject: [PATCHv4 0/5] git-rm absorbs submodule git directory before > deletion > > v4: > * reworded commit messages of

  1   2   3   4   5   6   7   8   9   10   >