On Mon, 2019-10-21 at 18:00 +0200, SZEDER Gábor wrote:
> Add the missing condition to trie_find() so it will never invoke the
> match function with a non-existing value. check_common() will then
> no
> longer have to check that it got a non-NULL value, so remove that
> condition.
...
>
> /
Signed-off-by: David Turner
---
Documentation/gitremote-helpers.txt | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 43f80c8068..a5c3c04371 100644
--- a/Documentation/gitremote
> -Original Message-
> From: Junio C Hamano
> Sent: Friday, August 30, 2019 1:35 PM
> To: David Turner
> Cc: Martin Ågren ; Git Mailing List
>
> Subject: Re: [PATCH] clarify documentation for remote helpers
>
> David Turner writes:
>
> > I was co
> -Original Message-
> From: Martin Ågren
> Sent: Friday, August 30, 2019 10:09 AM
> To: David Turner
> Cc: Git Mailing List
> Subject: Re: [PATCH v2] clarify documentation for remote helpers
>
> On Fri, 30 Aug 2019 at 16:00, David Turner wrote:
> >
&
Signed-off-by: David Turner
---
Documentation/gitremote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 43f80c8068..f4a165387f 100644
--- a/Documentation/gitremote-helpers.txt
y that it's the full path.
> -Original Message-
> From: Martin Ågren
> Sent: Friday, August 30, 2019 12:03 AM
> To: David Turner
> Cc: Git Mailing List
> Subject: Re: [PATCH] clarify documentation for remote helpers
>
> On Thu, 29 Aug 2019 at 23:06, David Turner wrote:
&
Signed-off-by: David Turner
---
This doesn't address the connectivity-ok problem, which I continue to
worry is a real bug. But it would have saved me a few minutes of
debugging.
Documentation/gitremote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
Quoth the git-remote-helpers man page:
"If option check-connectivity is requested, the helper must output
connectivity-ok if the clone is self-contained and connected."
I tried doing that in a helper, but I still got a connectivity check.
Looking at the code, it looks like this only works if I su
"1 file changed..." line]
>
> This patch teaches combine-diff to treats the two formats
> identically.
>
> Reported-by: David Turner
> Signed-off-by: Jeff King
> ---
> combine-diff.c | 1 +
> t/t4013-diff-various.sh
Thanks for adding the test.
On Fri, 2019-01-18 at 22:26 +, Eric Wong wrote:
> David Turner wrote:
> > Let's try this version.
>
> Thanks!
>
> Tested-by: Eric Wong
>
> Not sure if t1512 would be the best place to put the test, but
> having a repo with
Let's try this version.
On Fri, 2019-01-18 at 10:45 +, Eric Wong wrote:
> David Turner wrote:
> > It appears that get_oid_with_context calls into get_short_oid for
> > that
> > case, and get_short_oid returns SHORT_NAME_AMBIGUOUS, which is
> > -2. We
&g
hows the ambiguity and gives me hints, which is expected.
>
> Thanks.
>
From 319a4c76f1939a004775a3440d504e14f53074f3 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Thu, 17 Jan 2019 23:19:43 -0500
Subject: [PATCH] Do not print 'dangling' for cat-file in case of am
When a submodule is renamed, git log gives incorrect output:
commit 350ebece9bce8d9c495f9a51e6f5529749c5c3cc (HEAD -> master)
Author:
David Turner
Date: Wed Jan 2 17:09:56 2019 -0500
move
diff --git a/.gitmodules b/.gitmodules
index da1a767..f4baf2a 100644
--- a/.gitmodules
++
On December 17, 2018 5:57:50 PM EST, "Ævar Arnfjörð Bjarmason"
wrote:
>
>On Mon, Dec 17 2018, David Turner wrote:
>
>> Overall, I like this. One nit:
>
>Thanks for the review!
>
>> On December 17, 2018 5:16:25 PM EST, "Ævar Arnfjörð Bjarmason&quo
Overall, I like this. One nit:
On December 17, 2018 5:16:25 PM EST, "Ævar Arnfjörð Bjarmason"
wrote:
>--- a/upload-pack.c
>+++ b/upload-pack.c
>@@ -54,7 +54,8 @@ static int no_progress, daemon_mode;
> #define ALLOW_REACHABLE_SHA1 02
>/* Allow request of any sha1. Implies ALLOW_TIP_SHA1 and
>ALL
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 'js/
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 w
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 during my testing, and
On May 6, 2018 9:56:31 AM MDT, "Martin Ågren" wrote:
>On 6 May 2018 at 17:48, David Turner wrote:
>> On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote:
>>> While at it, make the lock non-static.
>
>> Re making the lock static, I wonder about the fol
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 functio
Re making the lock static, I wonder about the following case:
if (read_ref(pseudoref, &actual_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 sta
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
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
> find_dir
On Mon, 2017-12-11 at 12:27 -0800, Stefan Beller wrote:
> On Mon, Dec 4, 2017 at 1:39 PM, David Turner
> wrote:
> > 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
&
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
su
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 exa
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 that'
> -Original Message-
> From: Ben Peart [mailto:peart...@gmail.com]
> Sent: Tuesday, September 19, 2017 4:45 PM
> To: David Turner ; 'Ben Peart'
>
> Cc: ava...@gmail.com; christian.cou...@gmail.com; git@vger.kernel.org;
> gits...@pobox.com; johannes.schin
> -Original Message-
> From: Ben Peart [mailto:benpe...@microsoft.com]
> Sent: Tuesday, September 19, 2017 3:28 PM
> To: benpe...@microsoft.com
> Cc: David Turner ; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
> johannes.sc
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'
> Cc: ava...@gm
> -Original Message-
> From: Ben Peart [mailto:peart...@gmail.com]
> Sent: Monday, September 18, 2017 9:07 AM
> To: David Turner ; 'Ben Peart'
>
> Cc: ava...@gmail.com; christian.cou...@gmail.com; git@vger.kernel.org;
> gits...@pobox.com; johannes.schinde...
> -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 >dir2/new
> -Original Message-
> + # Choose integration script based on existance of Watchman.
Spelling: existence
> -Original Message-
> From: Ben Peart [mailto:benpe...@microsoft.com]
> Sent: Friday, September 15, 2017 3:21 PM
> To: benpe...@microsoft.com
> Cc: David Turner ; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
> johannes.sc
> -Original Message-
> From: Ben Peart [mailto:benpe...@microsoft.com]
> Sent: Friday, September 15, 2017 3:21 PM
> To: benpe...@microsoft.com
> Cc: David Turner ; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
> johannes.sc
> -Original Message-
> From: Ben Peart [mailto:benpe...@microsoft.com]
> Sent: Friday, September 15, 2017 3:21 PM
> To: benpe...@microsoft.com
> Cc: David Turner ; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
> johannes.sc
> -Original Message-
> From: Howard Chu [mailto:h...@symas.com]
> Sent: Monday, August 14, 2017 8:31 AM
> To: spea...@spearce.org
> Cc: David Turner ; ava...@gmail.com;
> ben.a...@acegi.com.au; dborow...@google.com; git@vger.kernel.org;
> gits...@pobox.com; mh
> -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.
It looks to me like git-fast-export doesn't export the mergetag header on a
commit. Is this intentional, or an oversight?
> -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
> Cc: git@vger.kernel.org; benpe...@microsoft.com; pclo...@gmail.com;
> johannes.schinde...@gmx.de; David Tur
$ 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 lo
r.kernel.org
> Cc: Junio C Hamano ; Ben Peart
> ; Nguyễn Thái Ngọc Duy ;
> Johannes Schindelin ; David Turner
> ; Jeff King ; Christian
> Couder ; Ævar Arnfjörð Bjarmason
>
> Subject: [WIP/PATCH 7/6] perf: add a performance test for core.fsmonitor
>
> Add a performance te
> -Original Message-
> From: Ben Peart [mailto:peart...@gmail.com]
> Sent: Thursday, May 18, 2017 12:58 PM
> To: Junio C Hamano ; David Turner
>
> Cc: 'Christian Couder' ; Johannes Schindelin
> ; git ; Nguyễn Thái Ngọc
> Duy ; Ben Peart
> Subject: R
> -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 ;
> p...@peff.net
>
> -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 ;
> p...@peff.net
> Sub
2 AM
> To: Johannes Schindelin
> Cc: git ; Junio C Hamano ; Nguyễn
> Thái Ngọc Duy ; Ben Peart ;
> David Turner
> Subject: Re: [PATCH 0/1] Preserve the untracked cache across checkout, reset
> --
> hard, etc
>
> (Adding Dave in Cc as it looks like he is involved.)
> -Original Message-
> From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de]
> Sent: Thursday, April 20, 2017 5:58 PM
> To: Jeff King
> Cc: David Turner ; git@vger.kernel.org
> Subject: Re: [PATCH] Increase core.packedGitLimit
>
> Hi Peff,
>
>
where near this large any time soon,
so this should prevent the failure.
Helped-by: Jeff King
Signed-off-by: David Turner
---
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..1c5de153a5 100644
--- a/git-comp
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Tuesday, April 18, 2017 1:50 PM
> To: David Turner
> Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org;
> jacob.kel...@gmail.com
> Subject: Re: [PATCH] repack: respect gc
> 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
> gar
> -Original Message-
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, April 18, 2017 10:51 PM
> To: Jonathan Nieder
> Cc: David Turner ; git@vger.kernel.org;
> l@web.de
> Subject: Re: [PATCH v3 2/2] xgethostname: handle long hostnames
>
&
d-off-by: David Turner
---
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 deletions(-)
diff --git a/bu
From: René Scharfe
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
Signed-off-by: Rene
I've added his code.
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 |
> -Original Message-
> From: René Scharfe [mailto:l@web.de]
> Sent: Tuesday, April 18, 2017 12:08 PM
> To: Junio C Hamano ; David Turner
...
> >> Of course, my_host is sized to HOST_NAME_MAX + 1 and we are comparing
> >> it with locking_host, so perhaps
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Tuesday, April 18, 2017 1:20 PM
> To: David Turner
> Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org;
> jacob.kel...@gmail.com
> Subject: Re: [PATCH] repack: respect gc
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Monday, April 17, 2017 11:42 PM
> To: David Turner
> Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org;
> jacob.kel...@gmail.com
> Subject: Re: [PATCH] repack: respect gc
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Monday, April 17, 2017 11:42 PM
> To: David Turner
> Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org;
> jacob.kel...@gmail.com
> Subject: Re: [PATCH] repack: respect gc
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Friday, April 14, 2017 3:34 PM
> To: David Turner
> Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org;
> jacob.kel...@gmail.com
> Subject: Re: [PATCH] repack: respect gc
s use 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
---
This ve
> -Original Message-
> From: Jonathan Nieder [mailto:jrnie...@gmail.com]
> Sent: Thursday, April 13, 2017 6:05 PM
> To: David Turner
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] xgethostname: handle long hostnames
>
> Hi,
>
> David Turner wrote:
>
nage the lock 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.
d-off-by: David Turner
---
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 deletions(-)
diff --git a/bu
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
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
>
> wrote:
> > > Git gc locks the repository (using a gc.pid file) so
> > > that other gc
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: ./objects/pack/
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
> Cc: Jeff King ; Johannes Sixt ; David Turner
> ; git@vger.kernel.org; SZEDER Gábor
>
> Subject: [PA
size.
Signed-off-by: David Turner
---
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
index fbdf7a815a..5e6747dbb4
> -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 05:03:49PM +
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
---
V5
> -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/1
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
---
cache.h
> -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 01:26:
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
---
This version fixes the definition of git_parse_ssize_t to return int.
Sorry for the
> -Original Message-
> From: Torsten Bögershausen [mailto:tbo...@web.de]
> Sent: Friday, March 31, 2017 12:22 AM
> To: David Turner ; git@vger.kernel.org
> Subject: Re: [PATCH] http.postbuffer: make a size_t
>
>
>
> On 30/03/17 22:29, 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.
Signed-off-by: David Turner
---
cache.h | 1 +
config.c | 17 +
http.c | 4 ++--
http.h | 2 +-
4
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
>
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
---
cache.h | 1 +
config.c | 17 +
http.c | 2 +-
3 files changed, 19
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 to
On Mon, 2017-03-13 at 10:51 -0700, Stefan Beller wrote:
> On Fri, Mar 10, 2017 at 1:06 PM, David Turner
> wrote:
> > Git reset --mixed ignores submodules which are not
> > initialized. I've
> > attached a demo script.
> >
> > On one hand, this matches
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 commit)"
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Thursday, February 23, 2017 2:44 PM
> To: David Turner
> Cc: Junio C Hamano ; git@vger.kernel.org;
> sand...@crustytoothpaste.net; Johannes Schindelin
> ; Eric Sunshine
> Subject: Re: [PATCH
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Wednesday, February 22, 2017 8:38 PM
> To: David Turner
> Cc: Junio C Hamano ; git@vger.kernel.org;
> sand...@crustytoothpaste.net; Johannes Schindelin
> ; Eric Sunshine
> Subject: Re: [PATCH
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) {
> +
> -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 K
> -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
> Cc: git@vger.kernel.org; sand...@crustytoothpaste.net; Johannes Schindelin
> ; Eric Sunshine
> ;
solete.
This fixes https://github.com/git-for-windows/git/issues/987
Signed-off-by: Johannes Schindelin
Signed-off-by: David Turner
---
This has been in git for Windows for a few months (without the
config.txt change). We've also been using it internally. So I think
it's time to merge ba
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.
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Friday, February 10, 2017 4:15 PM
> To: David Turner
> Cc: git@vger.kernel.org; pclo...@gmail.com; Junio C Hamano
>
> Subject: Re: [PATCH v5] gc: ignore old gc.log files
>
> > @
e Git is too dumb to try again.
Signed-off-by: David Turner
Helped-by: Jeff King
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 6 +
builtin/gc.c | 57 ++--
t/t6500-gc.sh| 15 +
3 files changed,
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Friday, February 10, 2017 3:09 PM
> To: David Turner
> Cc: git@vger.kernel.org; pclo...@gmail.com
> Subject: Re: [PATCH v3] gc: ignore old gc.log files
>
> On Fri, Feb 10, 2017 at 02:20:19PM -
e Git is too dumb to try again.
Signed-off-by: David Turner
Helped-by: Jeff King
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 6 +
builtin/gc.c | 59 ++--
t/t6500-gc.sh| 15
3 files changed,
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
Helped-by: Jeff King
---
Documentation/config.txt | 6
builtin/gc.c
pack 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
Helped-by: Jeff King
---
Documentation/config.txt | 6
builtin/gc.c
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
Helped-by:
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 tty there).
>
> So
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
Helped-by: Jeff King
---
Documentation/config.txt | 5 +
builtin/gc.c | 15 ++-
t/t6500-gc.sh
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 writes:
> > >
> > > > On second thought, perhap
On Wed, 2017-02-08 at 13:45 +0700, Duy Nguyen wrote:
> On Wed, Feb 8, 2017 at 8:03 AM, David Turner 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
> >> 329e6e8794 was this l
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 messa
1 - 100 of 1518 matches
Mail list logo
