Re: [PATCH 7/6] run-command: block signals between fork and execve

Eric Wong wrote: > Brandon Williams wrote: > > On 04/13, Eric Wong wrote: > > > @@ -277,6 +278,8 @@ static void child_err_spew(struct child_process *cmd, > > > struct child_err *cerr) > > > error_errno("exec '%s': cd to '%s' failed", > > >

Re: [PATCH 7/6] run-command: block signals between fork and execve

Brandon Williams wrote: > On 04/13, Eric Wong wrote: > > @@ -277,6 +278,8 @@ static void child_err_spew(struct child_process *cmd, > > struct child_err *cerr) > > error_errno("exec '%s': cd to '%s' failed", > > cmd->argv[0], cmd->dir); > >

Re: [PATCH 7/6] run-command: block signals between fork and execve

On 04/13, Eric Wong wrote: > @@ -277,6 +278,8 @@ static void child_err_spew(struct child_process *cmd, > struct child_err *cerr) > error_errno("exec '%s': cd to '%s' failed", > cmd->argv[0], cmd->dir); > break; > + case

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

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> 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

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

Nguyễn Thái Ngọc Duy writes: > 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 >

Re: [PATCH v3] unpack-trees: avoid duplicate ODB lookups during checkout

On Thu, Apr 13, 2017 at 04:11:31PM -0700, Junio C Hamano wrote: > g...@jeffhostetler.com writes: > > > + /* > > +* Fetch the tree from the ODB for each peer directory in the > > +* n commits. > > +* > > +* For 2- and 3-way traversals, we try to avoid hitting the > > +* ODB

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

On Thu, Apr 13, 2017 at 1:27 PM, David Turner wrote: > Git gc locks the repository (using a gc.pid file) so that other gcs > don't run concurrently. Make git repack respect this lock. > > Now repack, by default, will refuse to run at the same time as a gc. > This fixes a

Re: [PATCH v2 0/6] forking and threading

On 04/13, Jonathan Nieder wrote: > Brandon Williams wrote: > > > From what I can see, there are now no calls in the child process (after fork > > and before exec/_exit) which are not Async-Signal-Safe. This means that > > fork/exec in a threaded context should work without deadlock > > I don't

Re: [PATCH 7/6] run-command: block signals between fork and execve

On 04/13, Eric Wong wrote: > Brandon Williams wrote: > > v2 does a bit of restructuring based on comments from reviewers. I took the > > patch by Eric and broke it up and tweaked it a bit to flow better with v2. > > I > > left out the part of Eric's patch which did signal

Re: [PATCH v3] unpack-trees: avoid duplicate ODB lookups during checkout

g...@jeffhostetler.com writes: > + /* > + * Fetch the tree from the ODB for each peer directory in the > + * n commits. > + * > + * For 2- and 3-way traversals, we try to avoid hitting the > + * ODB twice for the same OID. This should yield a nice speed > + * up

Re: [PATCH] submodule--helper: fix typo in is_active error message

On 04/13, Stefan Beller wrote: > Signed-off-by: Stefan Beller > --- > builtin/submodule--helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c > index e42e671014..b1d4269e10 100644 > ---

Re: [PATCH] worktree add: add --lock option

Nguyễn Thái Ngọc Duy writes: > As explained in the document. This option has an advantage over the > command sequence "git worktree add && git worktree lock": there will be > no gap that somebody can accidentally "prune" the new worktree (or soon, > explicitly "worktree

Re: [PATCH v2 2/6] run-command: prepare command before forking

On 04/13, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > > In order to avoid allocation between 'fork()' and 'exec()' the argv > > array used in the exec call is prepared prior to forking the process. > > nit: s/(the argv array.*) is prepared/prepare \1/ > > Git's commit messages

Re: [PATCH v1 0/3] travis-ci: build docs with asciidoctor

Lars Schneider writes: > this is a mini series to build the documentation with asciidoctor in > addition to asciidoc on Travis-CI. Overall, this looks sensible. I didn't spot anything questionable other than a minor style nit, i.e. write these make doc

Re: [PATCH] xgethostname: handle long hostnames

Am 13.04.2017 um 21:23 schrieb David Turner: > If the full hostname doesn't fit in the buffer supplied to > gethostname, POSIX does not specify whether the buffer will be > null-terminated, so to be safe, we should do it ourselves. Introduce > new function, xgethostname, which ensures that there

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 > Cc: git@vger.kernel.org > Subject: Re: [PATCH] xgethostname: handle long hostnames > > Hi, > > David Turner wrote: > > > If

[PATCH] submodule--helper: fix typo in is_active error message

Signed-off-by: Stefan Beller --- builtin/submodule--helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c index e42e671014..b1d4269e10 100644 --- a/builtin/submodule--helper.c +++

Re: [PATCH] xgethostname: handle long hostnames

Hi, David Turner wrote: > If the full hostname doesn't fit in the buffer supplied to > gethostname, POSIX does not specify whether the buffer will be > null-terminated, so to be safe, we should do it ourselves. [...] > +++ b/wrapper.c > @@ -655,3 +655,16 @@ void sleep_millisec(int millisec) > {

Re: [PATCH 1/1] difftool: fix use-after-free

Johannes Schindelin wrote: > Signed-off-by: Johannes Schindelin > --- > builtin/difftool.c | 7 +-- > t/t7800-difftool.sh | 19 +++ > 2 files changed, 24 insertions(+), 2 deletions(-) Reviewed-by: Jonathan Nieder Thank

Re: [PATCH v2 1/6] t5550: use write_script to generate post-update hook

Brandon Williams wrote: > On 04/13, Eric Wong wrote: > > Jonathan Nieder wrote: > > > Brandon Williams wrote: > > > > The post-update hooks created in t5550-http-fetch-dumb.sh is missing the > > > > "!#/bin/sh" line which can cause issues with portability.

Re: [PATCH v2 1/6] t5550: use write_script to generate post-update hook

On 04/13, Eric Wong wrote: > Jonathan Nieder wrote: > > Brandon Williams wrote: > > > The post-update hooks created in t5550-http-fetch-dumb.sh is missing the > > > "!#/bin/sh" line which can cause issues with portability. Instead > > > create the hook using the

Re: [PATCH] Make git log work for git CWD outside of work tree

On Wed, Apr 12, 2017 at 08:11:22PM +0700, Duy Nguyen wrote: > On Wed, Apr 12, 2017 at 8:01 PM, Jeff King wrote: > > I dunno. Maybe I am missing some subtle case, but it's not clear to me > > what the user would be trying to do by having git stay in the original > > directory. > >

Re: [PATCH] xgethostname: handle long hostnames

On Thu, Apr 13, 2017 at 03:23:35PM -0400, David Turner wrote: > If the full hostname doesn't fit in the buffer supplied to > gethostname, POSIX does not specify whether the buffer will be > null-terminated Wow, TIL. What an utterly terrible and error-prone interface (I always just assumed we'd

Re: [PATCH v2 2/6] run-command: prepare command before forking

Hi, Brandon Williams wrote: > In order to avoid allocation between 'fork()' and 'exec()' the argv > array used in the exec call is prepared prior to forking the process. nit: s/(the argv array.*) is prepared/prepare \1/ Git's commit messages are in the imperative mood, as if they are ordering

[PATCH 7/6] run-command: block signals between fork and execve

Brandon Williams wrote: > v2 does a bit of restructuring based on comments from reviewers. I took the > patch by Eric and broke it up and tweaked it a bit to flow better with v2. I > left out the part of Eric's patch which did signal manipulation as I wasn't > experienced

Re: [PATCH v2 1/6] t5550: use write_script to generate post-update hook

Jonathan Nieder wrote: > Brandon Williams wrote: > > The post-update hooks created in t5550-http-fetch-dumb.sh is missing the > > "!#/bin/sh" line which can cause issues with portability. Instead > > create the hook using the 'write_script' function which includes the > >

Re: [PATCH v2 0/6] forking and threading

Brandon Williams wrote: > From what I can see, there are now no calls in the child process (after fork > and before exec/_exit) which are not Async-Signal-Safe. This means that > fork/exec in a threaded context should work without deadlock I don't see why the former implies the latter. Can you

Re: [PATCH v2 1/6] t5550: use write_script to generate post-update hook

Hi, Brandon Williams wrote: > The post-update hooks created in t5550-http-fetch-dumb.sh is missing the > "!#/bin/sh" line which can cause issues with portability. Instead > create the hook using the 'write_script' function which includes the > proper "#!" line. > > Signed-off-by: Brandon

"up-to-date" vs. "up to date"

Hello git community, This is about an issue of language style and punctuation, not anything functional. Apologies in advance if I've brought this to the wrong place. There are a bunch of situations in which git will print a message like "Your branch is up-to-date with 'origin/master'" or

[PATCH] repack: respect gc.pid lock

Git gc locks the repository (using a gc.pid file) so that other gcs don't run concurrently. Make git repack respect this lock. Now repack, by default, will refuse to run at the same time as a gc. This fixes a concurrency issue: a repack which deleted packs would make a concurrent gc sad when its

Re: Proposal for "fetch-any-blob Git protocol" and server design

On 04/12/2017 03:02 PM, Kevin David wrote: Hi Jonathan, I work on the network protocols for the GVFS project at Microsoft. I shared a couple thoughts and questions below. Thanks for your reply! I know we're considering server behavior here, but how large do you generally expect these

Re: [PATCH v2 4/6] run-command: don't die in child when duping /dev/null

On 04/13, Eric Wong wrote: > Brandon Williams wrote: > > @@ -487,7 +483,7 @@ int start_command(struct child_process *cmd) > > atexit(notify_parent); > > > > if (cmd->no_stdin) > > - dup_devnull(0); > > +

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 9:12 PM, Jeff King wrote: > On Thu, Apr 13, 2017 at 09:03:26PM +0200, SZEDER Gábor wrote: > >> > Yeah, I had a similar thought. I can't think of any reason why it would >> > trigger a false positive, as long as we account for test-failure and the >> >

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On Thu, Apr 13, 2017 at 12:25 PM, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 12:12 PM, Jacob Keller wrote: >> On Thu, Apr 13, 2017 at 12:05 PM, Stefan Beller wrote: >>> On Thu, Apr 13, 2017 at 11:57 AM, Brandon Williams

Re: [PATCH v2 4/6] run-command: don't die in child when duping /dev/null

Brandon Williams wrote: > @@ -487,7 +483,7 @@ int start_command(struct child_process *cmd) > atexit(notify_parent); > > if (cmd->no_stdin) > - dup_devnull(0); > + dup2(null_fd, 0); I prefer we keep error

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On Thu, Apr 13, 2017 at 12:12 PM, Jacob Keller wrote: > On Thu, Apr 13, 2017 at 12:05 PM, Stefan Beller wrote: >> On Thu, Apr 13, 2017 at 11:57 AM, Brandon Williams wrote: >>> Add in a check to see if a submodule is active before

[PATCH] xgethostname: handle long hostnames

If the full hostname doesn't fit in the buffer supplied to gethostname, POSIX does not specify whether the buffer will be null-terminated, so to be safe, we should do it ourselves. Introduce new function, xgethostname, which ensures that there is always a \0 at the end of the buffer.

[PATCH 1/1] difftool: fix use-after-free

The left and right base directories were pointed to the buf field of two strbufs, which were subject to change. A contrived test case shows the problem where a file with a long enough name to force the strbuf to grow is up-to-date (hence the code path is used where the work tree's version of the

[PATCH 0/1] difftool: fix a use-after-free bug

It has been reported previously that the base_dir recorded at the beginning of run_dir_diff() may go stale due to the buffer to which it points potentially being realloc()ed. This bug has been fixed in Git for Windows 2.12.2(2) already. It took me this long (!!!) to come up with a reliable test

Re: [PATCH 3/4] submodule.c: harden submodule_move_head against broken submodules

On Thu, Apr 13, 2017 at 12:08 PM, Brandon Williams wrote: > On 04/11, Stefan Beller wrote: >> Early on in submodule_move_head just after the check if the submodule is >> initialized, we need to check if the submodule is populated correctly. >> >> If the submodule is initialized

Re: [PATCH 2/4] submodule.c: uninitialized submodules are ignored in recursive commands

On 04/13, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 12:05 PM, Brandon Williams wrote: > > On 04/11, Stefan Beller wrote: > >> This was an oversight when working on the working tree modifying commands > >> recursing into submodules. > >> > >> To test for uninitialized

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 09:03:26PM +0200, SZEDER Gábor wrote: > > Yeah, I had a similar thought. I can't think of any reason why it would > > trigger a false positive, as long as we account for test-failure and the > > --debug flag properly. I don't think we can just drop the "-f" from the > >

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On Thu, Apr 13, 2017 at 12:05 PM, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 11:57 AM, Brandon Williams wrote: >> Add in a check to see if a submodule is active before attempting to >> recurse. This prevents 'ls-files' from trying to operate on a

Re: [PATCH 2/4] submodule.c: uninitialized submodules are ignored in recursive commands

On Thu, Apr 13, 2017 at 12:05 PM, Brandon Williams wrote: > On 04/11, Stefan Beller wrote: >> This was an oversight when working on the working tree modifying commands >> recursing into submodules. >> >> To test for uninitialized submodules, introduce another submodule, that is

Re: [PATCH 3/4] submodule.c: harden submodule_move_head against broken submodules

On 04/11, Stefan Beller wrote: > Early on in submodule_move_head just after the check if the submodule is > initialized, we need to check if the submodule is populated correctly. > > If the submodule is initialized but doesn't look like populated, this > is a red flag and can indicate multiple

Re: [PATCH 2/4] submodule.c: uninitialized submodules are ignored in recursive commands

On 04/11, Stefan Beller wrote: > This was an oversight when working on the working tree modifying commands > recursing into submodules. > > To test for uninitialized submodules, introduce another submodule, that is > uninitialized in the actual tests. By adding it to the branch "add_sub1", >

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On Thu, Apr 13, 2017 at 11:57 AM, Brandon Williams wrote: > Add in a check to see if a submodule is active before attempting to > recurse. This prevents 'ls-files' from trying to operate on a submodule > which may not exist in the working directory. What would currently

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 Thu, Apr 13, 2017 at 10:31 AM, David

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 7:57 PM, Jeff King wrote: > On Thu, Apr 13, 2017 at 10:55:08AM -0700, Stefan Beller wrote: > >> On Thu, Apr 13, 2017 at 9:37 AM, Jeff King wrote: >> > Ah, OK, that makes more sense. I can detect it reliably by just checking >> > >> > ! test

[PATCH 3/2] ls-files: only recurse on active submodules

Add in a check to see if a submodule is active before attempting to recurse. This prevents 'ls-files' from trying to operate on a submodule which may not exist in the working directory. Signed-off-by: Brandon Williams --- After you mentioned possibly needing to check if a

Re: Simultaneous gc and repack

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 Thu, Apr 13, 2017 at 10:31 AM, David Turner > > > > wrote: > > > > Git gc locks the

Re: [PATCH v2 1/2] ls-files: fix recurse-submodules with nested submodules

On 04/13, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 11:31 AM, Jacob Keller wrote: > > Spinning out a process is one of the big downsides of working with > > submodules in our code. Unfortunately, spinning out a process is also > > one of the biggest ways we isolate

Re: Simultaneous gc and repack

On Thu, Apr 13, 2017 at 11:28 AM, 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 Thu, Apr 13, 2017 at 10:31 AM, David Turner >> >> wrote: >> > > Git gc

[PATCH v2 2/6] run-command: prepare command before forking

In order to avoid allocation between 'fork()' and 'exec()' the argv array used in the exec call is prepared prior to forking the process. In addition to this, the function used to exec is changed from 'execvp()' to 'execv()' as the (p) variant of exec has the potential to call malloc during the

Re: [PATCH v2 1/2] ls-files: fix recurse-submodules with nested submodules

On Thu, Apr 13, 2017 at 11:31 AM, Jacob Keller wrote: > Spinning out a process is one of the big downsides of working with > submodules in our code. Unfortunately, spinning out a process is also > one of the biggest ways we isolate submodules, and if we wanted to do > this

[PATCH v2 6/6] run-command: add note about forking and threading

All non-Async-Signal-Safe functions (e.g. malloc and die) were removed between 'fork' and 'exec' in start_command in order to avoid potential deadlocking when forking while multiple threads are running. This deadlocking is possible when a thread (other than the one forking) has acquired a lock

[PATCH v2 3/6] run-command: prepare child environment before forking

In order to avoid allocation between 'fork()' and 'exec()' prepare the environment to be used in the child process prior to forking. Switch to using 'execve()' so that the construct child environment can used in the exec'd process. Signed-off-by: Brandon Williams ---

Re: [PATCH v2 2/2] ls-files: fix path used when recursing into submodules

On Thu, Apr 13, 2017 at 11:15 AM, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 10:12 AM, Jacob Keller > wrote: >> From: Jacob Keller >> >> Don't assume that the current working directory is the root of the >> repository. >

[PATCH v2 4/6] run-command: don't die in child when duping /dev/null

Signed-off-by: Brandon Williams --- run-command.c | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/run-command.c b/run-command.c index 5e2a03145..6751b8319 100644 --- a/run-command.c +++ b/run-command.c @@ -117,18 +117,6 @@

[PATCH v2 1/6] t5550: use write_script to generate post-update hook

The post-update hooks created in t5550-http-fetch-dumb.sh is missing the "!#/bin/sh" line which can cause issues with portability. Instead create the hook using the 'write_script' function which includes the proper "#!" line. Signed-off-by: Brandon Williams ---

[PATCH v2 5/6] run-command: eliminate calls to error handling functions in child

All of our standard error handling paths have the potential to call malloc or take stdio locks; so we must avoid them inside the forked child. Instead, the child only writes an 8 byte struct atomically to the parent through the notification pipe to propagate an error. All user-visible error

[PATCH v2 0/6] forking and threading

v2 does a bit of restructuring based on comments from reviewers. I took the patch by Eric and broke it up and tweaked it a bit to flow better with v2. I left out the part of Eric's patch which did signal manipulation as I wasn't experienced enough to know what it was doing or why it was

Re: [PATCH v2 1/2] ls-files: fix recurse-submodules with nested submodules

On Thu, Apr 13, 2017 at 11:03 AM, Brandon Williams wrote: > On 04/13, Jacob Keller wrote: >> From: Jacob Keller >> >> Since commit e77aa336f116 ("ls-files: optionally recurse into >> submodules", 2016-10-07) ls-files has known how to recurse into >>

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  > > wrote: > > > Git gc locks the repository (using a gc.pid file) so > > > that other gcs don't run

Re: [PATCH v2 2/2] ls-files: fix path used when recursing into submodules

On Thu, Apr 13, 2017 at 10:12 AM, Jacob Keller wrote: > From: Jacob Keller > > Don't assume that the current working directory is the root of the > repository. 1) Oh! This bug might be hidden in other commands, too. ($ git grep cp.dir --

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

On Thu, Apr 13, 2017 at 08:08:12PM +0200, SZEDER Gábor wrote: > On Thu, Apr 13, 2017 at 6:44 PM, Jeff King wrote: > > On Thu, Apr 13, 2017 at 12:31:38PM +0200, SZEDER Gábor wrote: > > > I did wonder what will happen if Windows learns to daemonize() the > > auto-gc. I don't think

Re: [PATCH v2 2/2] ls-files: fix path used when recursing into submodules

On 04/13, Jacob Keller wrote: > From: Jacob Keller > > Don't assume that the current working directory is the root of the > repository. Correctly generate the path for the recursing child > processes by building it from the work_tree() root instead. Otherwise if > we run

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

On Thu, Apr 13, 2017 at 6:44 PM, Jeff King wrote: > On Thu, Apr 13, 2017 at 12:31:38PM +0200, SZEDER Gábor wrote: > I did wonder what will happen if Windows learns to daemonize() the > auto-gc. I don't think we'll get an immediate test failure, but this > test will become racy

Re: Simultaneous gc and repack

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 gcs don't run concurrently. But git repack > > doesn't respect this lock, so it's

Re: [PATCH v2 1/2] ls-files: fix recurse-submodules with nested submodules

On 04/13, Jacob Keller wrote: > From: Jacob Keller > > Since commit e77aa336f116 ("ls-files: optionally recurse into > submodules", 2016-10-07) ls-files has known how to recurse into > submodules when displaying files. > > Unfortunately this fails for certain cases,

Re: Simultaneous gc and repack

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

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 10:55:08AM -0700, Stefan Beller wrote: > On Thu, Apr 13, 2017 at 9:37 AM, Jeff King wrote: > > Ah, OK, that makes more sense. I can detect it reliably by just checking > > > > ! test -d $root/trash* > > > > in my stress-test after the test successfully

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 9:37 AM, Jeff King wrote: > Ah, OK, that makes more sense. I can detect it reliably by just checking > > ! test -d $root/trash* > > in my stress-test after the test successfully completes. Would we want to report such an error from the test suite itself?

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: [PATCH] submodule.c: add missing ' in error messages

On Thu, Apr 13, 2017 at 9:40 AM, Ralf Thielow wrote: > Signed-off-by: Ralf Thielow > --- Thanks! Reviewed-by: Stefan Beller

[PATCH v2 2/2] ls-files: fix path used when recursing into submodules

From: Jacob Keller Don't assume that the current working directory is the root of the repository. Correctly generate the path for the recursing child processes by building it from the work_tree() root instead. Otherwise if we run ls-files using --git-dir or --work-tree it

[PATCH v2 1/2] ls-files: fix recurse-submodules with nested submodules

From: Jacob Keller Since commit e77aa336f116 ("ls-files: optionally recurse into submodules", 2016-10-07) ls-files has known how to recurse into submodules when displaying files. Unfortunately this fails for certain cases, including when nesting more than one submodule,

Errors running gitk on OS X

Running gitk from the command line, while at the top level of a Git working directory, produces the following error message, and gitk fails to open: > objc[1031]: Objective-C garbage collection is no longer supported. > /usr/local/bin/wish: line 2: 1031 Abort trap: 6 "$(dirname >

Fwd: Errors running gitk on OS X

Running gitk from the command line, while at the top level of a Git working directory, produces the following error message, and gitk fails to open: > objc[1031]: Objective-C garbage collection is no longer supported. > /usr/local/bin/wish: line 2: 1031 Abort trap: 6 "$(dirname >

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

On Thu, Apr 13, 2017 at 12:31:38PM +0200, SZEDER Gábor wrote: > Note, that this fd trickery doesn't work on Windows, because due to > MSYS limitations the git process only inherits the standard fds 0, 1 > and 2 from the shell. Luckily, it doesn't matter in this case, > because on Windows

[PATCH] git-add--interactive.perl: add missing dot in a message

One message appears twice in the translations and the only difference is a dot at the end. So add this dot to make the messages being identical. Signed-off-by: Ralf Thielow --- git-add--interactive.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] submodule.c: add missing ' in error messages

Signed-off-by: Ralf Thielow --- submodule.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/submodule.c b/submodule.c index c52d6634c..02033c97e 100644 --- a/submodule.c +++ b/submodule.c @@ -1251,7 +1251,7 @@ int bad_to_remove_submodule(const char

Re: [PATCH] t6500: don't run detached auto gc at the end of the test script

On Thu, Apr 13, 2017 at 12:03:20AM +0200, SZEDER Gábor wrote: > > I couldn't get the original to show a failure, though, even under heavy > > load. So maybe widening the race is enough. > > Just to be clear: it's only an occasionally appearing error message. > There is no failure in the sense of

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 > Cc: Jeff King ; Johannes Sixt ; David Turner > ;

[PATCH v3] unpack-trees: avoid duplicate ODB lookups during checkout

From: Jeff Hostetler Version 3 uses a structure copy rather than memcpy and adds a comment. Jeff Hostetler (1): unpack-trees: avoid duplicate ODB lookups during checkout unpack-trees.c | 37 + 1 file changed, 33 insertions(+), 4

[PATCH v3] unpack-trees: avoid duplicate ODB lookups during checkout

From: Jeff Hostetler Teach traverse_trees_recursive() to not do redundant ODB lookups when both directories refer to the same OID. In operations such as read-tree and checkout, there will likely be many peer directories that have the same OID when the differences between

Re: [PATCH 5/7] Add support for gnupg < 1.4

On Wed, Apr 5, 2017 at 3:45 PM, Ævar Arnfjörð Bjarmason wrote: > On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen > wrote: >> This adds an OLD_GNUPG define to the Makefile which when activated will >> ensure git does not use the --keyid-format argument

Re: Rebase sequencer changes prevent exec commands from modifying the todo file?

Hi Stephen, On Wed, 12 Apr 2017, Stephen Hicks wrote: > On Wed, Apr 12, 2017 at 3:05 PM, Johannes Schindelin > wrote: > > > > On Tue, 11 Apr 2017, Stephen Hicks wrote: > > > > > I'm hesitant to only use mtime, size, and inode, since it's quite > > > likely that these

gitk feature request: checkout any commit

Hello, it would be helpful, if gitk would allow checkouts not only for local branches but also for remote branches and any other commit. For remote branches, it is sufficient to remove the code that greys out the context menu. The context menu for regular commits would need a new entry.

Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

On Wed, Apr 12, 2017 at 11:28 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Wed, Apr 05, 2017 at 03:04:24PM +0200, Tom G. Christensen wrote: >> ... >> These kinds of interleaved conditionals make me nervous that we'll get >> something wrong (especially

Re: [PATCH] status: show in-progress info for short status

On Fri, Apr 7, 2017 at 4:05 PM, Michael J Gruber wrote: > SZEDER Gábor venit, vidit, dixit 06.04.2017 16:33: >>> @@ -1779,6 +1780,31 @@ static void wt_shortstatus_print_tracking(struct >>> wt_status *s) >>> } >>> >>> color_fprintf(s->fp, header_color, "]"); >>> + >>> +

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

The last test in 't6500-gc', 'background auto gc does not run if gc.log is present and recent but does if it is old', added in a831c06a2 (gc: ignore old gc.log files, 2017-02-10), may sporadically trigger an error message from the test harness: rm: cannot remove 'trash

Re: [PATCH] status: show in-progress info for short status

On Wed, Apr 12, 2017 at 11:09 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> Personally, I would want this to become the default and not have a new >> option to trigger it. I think we could also extend the porcelain >> format to include this

Re: [PATCH] status: show in-progress info for short status

On Wed, Apr 12, 2017 at 11:09 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> Personally, I would want this to become the default and not have a new >> option to trigger it. I think we could also extend the porcelain >> format to include this

Re: [PATCH 5/7] Add support for gnupg < 1.4

Ævar Arnfjörð Bjarmason writes: > On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen > wrote: >> This adds an OLD_GNUPG define to the Makefile which when activated will >> ensure git does not use the --keyid-format argument when calling the >> 'gpg'

Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

Jeff King writes: > On Wed, Apr 05, 2017 at 03:04:24PM +0200, Tom G. Christensen wrote: > ... > These kinds of interleaved conditionals make me nervous that we'll get > something wrong (especially without braces, it's not immediately clear > that both sides are a single

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

g...@jeffhostetler.com writes: > 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

Re: [PATCH] status: show in-progress info for short status

Jacob Keller writes: > Personally, I would want this to become the default and not have a new > option to trigger it. I think we could also extend the porcelain > format to include this information as well, but I'm not too familiar > with how the v2 format extends or not.