{"thread":{"id":"49529","subject":"[PATCH] revert & cherry-pick: run git gc --auto","startedAt":"2018-10-10T19:36:09Z","lastAt":"2018-10-11T11:24:11Z","messageCount":7,"participants":["Ævar Arnfjörð Bjarmason","Phillip Wood","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"360062","messageId":"20181010193557.19052-1-avarab@gmail.com","threadId":"49529","inReplyTo":null,"subject":"[PATCH] revert & cherry-pick: run git gc --auto","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-10T19:35:57Z","receivedAt":"2018-10-10T19:36:09Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Expand on the work started in 095c741edd (\"commit: run git gc --auto\njust before the post-commit hook\", 2018-02-28) to run \"gc --auto\" in\nmore commands where new objects can be created.\n\nThe notably missing commands are now \"rebase\" and \"stash\". Both are\nbeing rewritten in C, so any use of \"gc --auto\" there can wait for\nthat.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\nAfter reading the \"Users are encouraged to run this task...\" paragraph\nin the git-gc manpage I was wondering if due to gc --auto all over the\nplace now (including recently in git-commit with a patch of mine) if\nwe shouldn't change that advice.\n\nI'm meaning to send some doc changes to git-gc.txt, but in the\nmeantime let's address this low-hanging fruit of running gc --auto\nwhen we revert or cherry-pick commits, which can like git-commit\ncreate a significant amount of loose objects.\n\n builtin/revert.c | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/builtin/revert.c b/builtin/revert.c\nindex 9a66720cfc..1b20902910 100644\n--- a/builtin/revert.c\n+++ b/builtin/revert.c\n@@ -209,6 +209,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n {\n \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n \tint res;\n+\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n \n \tif (isatty(0))\n \t\topts.edit = 1;\n@@ -217,6 +218,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n \tres = run_sequencer(argc, argv, &opts);\n \tif (res < 0)\n \t\tdie(_(\"revert failed\"));\n+\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n \treturn res;\n }\n \n@@ -224,11 +226,13 @@ int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n {\n \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n \tint res;\n+\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n \n \topts.action = REPLAY_PICK;\n \tsequencer_init_config(&opts);\n \tres = run_sequencer(argc, argv, &opts);\n \tif (res < 0)\n \t\tdie(_(\"cherry-pick failed\"));\n+\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n \treturn res;\n }\n-- \n2.19.1.390.gf3a00b506f\n\n"},{"id":"360155","messageId":"20f33df8-7ba8-af26-e0c8-16152345c85b@talktalk.net","threadId":"49529","inReplyTo":"20181010193557.19052-1-avarab@gmail.com","subject":"Re: [PATCH] revert & cherry-pick: run git gc --auto","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2018-10-11T09:23:11Z","receivedAt":"2018-10-11T09:23:15Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Ævar\n\nOn 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:\n> Expand on the work started in 095c741edd (\"commit: run git gc --auto\n> just before the post-commit hook\", 2018-02-28) to run \"gc --auto\" in\n> more commands where new objects can be created.\n> \n> The notably missing commands are now \"rebase\" and \"stash\". Both are\n> being rewritten in C, so any use of \"gc --auto\" there can wait for\n> that.\n\nIf cherry-pick, revert or 'rebase -i' edit the commit message then they\nfork 'git commit' so gc --auto will be run there anyway. I wonder if it\nwould be better to call 'gc --auto' from sequencer.c at the end of a\nstring of successful picks, that would cover cherry-pick, 'rebase -iu'\nand revert. With 'rebase -i' it might be nice to avoid calling 'gc\n--auto' until the very end, rather than every time we stop for an edit\nbut that is probably more trouble than it is worth.\n\nBest Wishes\n\nPhillip\n\n> \n> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> ---\n> \n> After reading the \"Users are encouraged to run this task...\" paragraph\n> in the git-gc manpage I was wondering if due to gc --auto all over the\n> place now (including recently in git-commit with a patch of mine) if\n> we shouldn't change that advice.\n> \n> I'm meaning to send some doc changes to git-gc.txt, but in the\n> meantime let's address this low-hanging fruit of running gc --auto\n> when we revert or cherry-pick commits, which can like git-commit\n> create a significant amount of loose objects.\n> \n>  builtin/revert.c | 4 ++++\n>  1 file changed, 4 insertions(+)\n> \n> diff --git a/builtin/revert.c b/builtin/revert.c\n> index 9a66720cfc..1b20902910 100644\n> --- a/builtin/revert.c\n> +++ b/builtin/revert.c\n> @@ -209,6 +209,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n>  {\n>  \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n>  \tint res;\n> +\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n>  \n>  \tif (isatty(0))\n>  \t\topts.edit = 1;\n> @@ -217,6 +218,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n>  \tres = run_sequencer(argc, argv, &opts);\n>  \tif (res < 0)\n>  \t\tdie(_(\"revert failed\"));\n> +\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>  \treturn res;\n>  }\n>  \n> @@ -224,11 +226,13 @@ int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n>  {\n>  \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n>  \tint res;\n> +\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n>  \n>  \topts.action = REPLAY_PICK;\n>  \tsequencer_init_config(&opts);\n>  \tres = run_sequencer(argc, argv, &opts);\n>  \tif (res < 0)\n>  \t\tdie(_(\"cherry-pick failed\"));\n> +\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>  \treturn res;\n>  }\n> \n\n"},{"id":"360165","messageId":"87ftxceqxc.fsf@evledraar.gmail.com","threadId":"49529","inReplyTo":"20f33df8-7ba8-af26-e0c8-16152345c85b@talktalk.net","subject":"Re: [PATCH] revert & cherry-pick: run git gc --auto","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-11T10:08:47Z","receivedAt":"2018-10-11T10:08:53Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 11 2018, Phillip Wood wrote:\n\n> Hi Ævar\n>\n> On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:\n>> Expand on the work started in 095c741edd (\"commit: run git gc --auto\n>> just before the post-commit hook\", 2018-02-28) to run \"gc --auto\" in\n>> more commands where new objects can be created.\n>>\n>> The notably missing commands are now \"rebase\" and \"stash\". Both are\n>> being rewritten in C, so any use of \"gc --auto\" there can wait for\n>> that.\n>\n> If cherry-pick, revert or 'rebase -i' edit the commit message then they\n> fork 'git commit' so gc --auto will be run there anyway.\n\nYeah it seems I totally screwed up the testing for this patch, first it\ndoesn't even compile because I'm not including run-command.h, I *did*\nfix that, but while wrangling a few things didn't commit that *sigh*.\n\nAnd yeah, there's some invocations where we now run gc --auto twice,\ni.e. if you do revert, but not revert --no-edit, and not on cherry-pick,\nbut on cherry-pick --edit.\n\nSo yeah, this really needs to be re-thought.\n\n> I wonder if it would be better to call 'gc --auto' from sequencer.c at\n> the end of a string of successful picks, that would cover cherry-pick,\n> 'rebase -iu' and revert. With 'rebase -i' it might be nice to avoid\n> calling 'gc --auto' until the very end, rather than every time we stop\n> for an edit but that is probably more trouble than it is worth.\n\nThat seems a lot better indeed. I.e. running it from the sequencer. I do\nwonder if there should be some smarts about running it in the middle of\na sequence, i.e. think of a case where we're rebasing 10k commits, which\nis a gc need similar to what happens in the middle of \"git svn\nclone\". So maybe something where we gc --auto in the sequencer for every\nNth commit, and at the end.\n\n>\n>>\n>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>> ---\n>>\n>> After reading the \"Users are encouraged to run this task...\" paragraph\n>> in the git-gc manpage I was wondering if due to gc --auto all over the\n>> place now (including recently in git-commit with a patch of mine) if\n>> we shouldn't change that advice.\n>>\n>> I'm meaning to send some doc changes to git-gc.txt, but in the\n>> meantime let's address this low-hanging fruit of running gc --auto\n>> when we revert or cherry-pick commits, which can like git-commit\n>> create a significant amount of loose objects.\n>>\n>>  builtin/revert.c | 4 ++++\n>>  1 file changed, 4 insertions(+)\n>>\n>> diff --git a/builtin/revert.c b/builtin/revert.c\n>> index 9a66720cfc..1b20902910 100644\n>> --- a/builtin/revert.c\n>> +++ b/builtin/revert.c\n>> @@ -209,6 +209,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n>>  {\n>>  \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n>>  \tint res;\n>> +\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n>>\n>>  \tif (isatty(0))\n>>  \t\topts.edit = 1;\n>> @@ -217,6 +218,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n>>  \tres = run_sequencer(argc, argv, &opts);\n>>  \tif (res < 0)\n>>  \t\tdie(_(\"revert failed\"));\n>> +\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>>  \treturn res;\n>>  }\n>>\n>> @@ -224,11 +226,13 @@ int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n>>  {\n>>  \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n>>  \tint res;\n>> +\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n>>\n>>  \topts.action = REPLAY_PICK;\n>>  \tsequencer_init_config(&opts);\n>>  \tres = run_sequencer(argc, argv, &opts);\n>>  \tif (res < 0)\n>>  \t\tdie(_(\"cherry-pick failed\"));\n>> +\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>>  \treturn res;\n>>  }\n>>\n"},{"id":"360167","messageId":"20181011102525.GH23446@szeder.dev","threadId":"49529","inReplyTo":"87ftxceqxc.fsf@evledraar.gmail.com","subject":"Re: [PATCH] revert & cherry-pick: run git gc --auto","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-11T10:25:25Z","receivedAt":"2018-10-11T10:25:31Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Oct 11, 2018 at 12:08:47PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Oct 11 2018, Phillip Wood wrote:\n> \n> > Hi Ævar\n> >\n> > On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:\n> >> Expand on the work started in 095c741edd (\"commit: run git gc --auto\n> >> just before the post-commit hook\", 2018-02-28) to run \"gc --auto\" in\n> >> more commands where new objects can be created.\n> >>\n> >> The notably missing commands are now \"rebase\" and \"stash\". Both are\n> >> being rewritten in C, so any use of \"gc --auto\" there can wait for\n> >> that.\n> >\n> > If cherry-pick, revert or 'rebase -i' edit the commit message then they\n> > fork 'git commit' so gc --auto will be run there anyway.\n> \n> Yeah it seems I totally screwed up the testing for this patch, first it\n> doesn't even compile because I'm not including run-command.h, I *did*\n> fix that, but while wrangling a few things didn't commit that *sigh*.\n> \n> And yeah, there's some invocations where we now run gc --auto twice,\n> i.e. if you do revert, but not revert --no-edit, and not on cherry-pick,\n> but on cherry-pick --edit.\n> \n> So yeah, this really needs to be re-thought.\n> \n> > I wonder if it would be better to call 'gc --auto' from sequencer.c at\n> > the end of a string of successful picks, that would cover cherry-pick,\n> > 'rebase -iu' and revert. With 'rebase -i' it might be nice to avoid\n> > calling 'gc --auto' until the very end, rather than every time we stop\n> > for an edit but that is probably more trouble than it is worth.\n> \n> That seems a lot better indeed. I.e. running it from the sequencer. I do\n> wonder if there should be some smarts about running it in the middle of\n> a sequence, i.e. think of a case where we're rebasing 10k commits, which\n> is a gc need similar to what happens in the middle of \"git svn\n> clone\". So maybe something where we gc --auto in the sequencer for every\n> Nth commit, and at the end.\n\nHow would that affect setups with 'gc.autoDetach = false', or, more\nimportantly, platforms, where 'git gc --auto' always runs in the\nforeground?\n\n"},{"id":"360168","messageId":"87efcwepqc.fsf@evledraar.gmail.com","threadId":"49529","inReplyTo":"20181011102525.GH23446@szeder.dev","subject":"Re: [PATCH] revert & cherry-pick: run git gc --auto","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-11T10:34:35Z","receivedAt":"2018-10-11T10:34:40Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 11 2018, SZEDER Gábor wrote:\n\n> On Thu, Oct 11, 2018 at 12:08:47PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> On Thu, Oct 11 2018, Phillip Wood wrote:\n>>\n>> > Hi Ævar\n>> >\n>> > On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:\n>> >> Expand on the work started in 095c741edd (\"commit: run git gc --auto\n>> >> just before the post-commit hook\", 2018-02-28) to run \"gc --auto\" in\n>> >> more commands where new objects can be created.\n>> >>\n>> >> The notably missing commands are now \"rebase\" and \"stash\". Both are\n>> >> being rewritten in C, so any use of \"gc --auto\" there can wait for\n>> >> that.\n>> >\n>> > If cherry-pick, revert or 'rebase -i' edit the commit message then they\n>> > fork 'git commit' so gc --auto will be run there anyway.\n>>\n>> Yeah it seems I totally screwed up the testing for this patch, first it\n>> doesn't even compile because I'm not including run-command.h, I *did*\n>> fix that, but while wrangling a few things didn't commit that *sigh*.\n>>\n>> And yeah, there's some invocations where we now run gc --auto twice,\n>> i.e. if you do revert, but not revert --no-edit, and not on cherry-pick,\n>> but on cherry-pick --edit.\n>>\n>> So yeah, this really needs to be re-thought.\n>>\n>> > I wonder if it would be better to call 'gc --auto' from sequencer.c at\n>> > the end of a string of successful picks, that would cover cherry-pick,\n>> > 'rebase -iu' and revert. With 'rebase -i' it might be nice to avoid\n>> > calling 'gc --auto' until the very end, rather than every time we stop\n>> > for an edit but that is probably more trouble than it is worth.\n>>\n>> That seems a lot better indeed. I.e. running it from the sequencer. I do\n>> wonder if there should be some smarts about running it in the middle of\n>> a sequence, i.e. think of a case where we're rebasing 10k commits, which\n>> is a gc need similar to what happens in the middle of \"git svn\n>> clone\". So maybe something where we gc --auto in the sequencer for every\n>> Nth commit, and at the end.\n>\n> How would that affect setups with 'gc.autoDetach = false', or, more\n> importantly, platforms, where 'git gc --auto' always runs in the\n> foreground?\n\nI see we define NO_POSIX_GOODIES on Windows/MinGW, so those don't\ndemonize \"gc\", but then I'm confused by this which seems to imply the\nopposite: https://github.com/Microsoft/vscode/issues/29901\n\nAs far as the general UI question goes, I think if you define\ngc.autoDetach=true you're already OK with having \"git fetch\" and various\ncommands that produce commits block, so I don't see a big difference in\ndoing this in the middle of a rebase.\n\nBut it seems (aside from the question of how this is done on Windows)\nthat we demonize by default everywhere now, so I think it's OK to be\nless conservative about where we run gc.\n\nWe also run a GC every 1000th commit in \"git svn clone/rebase\" already.\n"},{"id":"360173","messageId":"65275c82-1fc0-8f89-8c13-562b73f3ffcf@talktalk.net","threadId":"49529","inReplyTo":"87ftxceqxc.fsf@evledraar.gmail.com","subject":"Re: [PATCH] revert & cherry-pick: run git gc --auto","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2018-10-11T11:14:31Z","receivedAt":"2018-10-11T11:14:37Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Ævar\nOn 11/10/2018 11:08, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Oct 11 2018, Phillip Wood wrote:\n> \n>> Hi Ævar\n>>\n>> On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:\n>>> Expand on the work started in 095c741edd (\"commit: run git gc --auto\n>>> just before the post-commit hook\", 2018-02-28) to run \"gc --auto\" in\n>>> more commands where new objects can be created.\n>>>\n>>> The notably missing commands are now \"rebase\" and \"stash\". Both are\n>>> being rewritten in C, so any use of \"gc --auto\" there can wait for\n>>> that.\n>>\n>> If cherry-pick, revert or 'rebase -i' edit the commit message then they\n>> fork 'git commit' so gc --auto will be run there anyway.\n> \n> Yeah it seems I totally screwed up the testing for this patch, first it\n> doesn't even compile because I'm not including run-command.h, I *did*\n> fix that, but while wrangling a few things didn't commit that *sigh*.\n> \n> And yeah, there's some invocations where we now run gc --auto twice,\n> i.e. if you do revert, but not revert --no-edit, and not on cherry-pick,\n> but on cherry-pick --edit.\n> \n> So yeah, this really needs to be re-thought.\n> \n>> I wonder if it would be better to call 'gc --auto' from sequencer.c at\n>> the end of a string of successful picks, that would cover cherry-pick,\n>> 'rebase -iu' and revert. With 'rebase -i' it might be nice to avoid\n>> calling 'gc --auto' until the very end, rather than every time we stop\n>> for an edit but that is probably more trouble than it is worth.\n> \n> That seems a lot better indeed. I.e. running it from the sequencer. I do\n> wonder if there should be some smarts about running it in the middle of\n> a sequence, i.e. think of a case where we're rebasing 10k commits, which\n> is a gc need similar to what happens in the middle of \"git svn\n> clone\". So maybe something where we gc --auto in the sequencer for every\n> Nth commit, and at the end.\n\nThat sounds like a good idea. It would be nice if need_to_gc() was in \nlibgit, then we could avoid the cost of forking unless we actually need \nto gc. Looking at builtin/gc.c there seem to be quite a few global \nvariables so transforming it to library code may not be that straight \nforward.\n\nBest Wishes\n\nPhillip\n\n>>\n>>>\n>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>> ---\n>>>\n>>> After reading the \"Users are encouraged to run this task...\" paragraph\n>>> in the git-gc manpage I was wondering if due to gc --auto all over the\n>>> place now (including recently in git-commit with a patch of mine) if\n>>> we shouldn't change that advice.\n>>>\n>>> I'm meaning to send some doc changes to git-gc.txt, but in the\n>>> meantime let's address this low-hanging fruit of running gc --auto\n>>> when we revert or cherry-pick commits, which can like git-commit\n>>> create a significant amount of loose objects.\n>>>\n>>>   builtin/revert.c | 4 ++++\n>>>   1 file changed, 4 insertions(+)\n>>>\n>>> diff --git a/builtin/revert.c b/builtin/revert.c\n>>> index 9a66720cfc..1b20902910 100644\n>>> --- a/builtin/revert.c\n>>> +++ b/builtin/revert.c\n>>> @@ -209,6 +209,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n>>>   {\n>>>   \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n>>>   \tint res;\n>>> +\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n>>>\n>>>   \tif (isatty(0))\n>>>   \t\topts.edit = 1;\n>>> @@ -217,6 +218,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n>>>   \tres = run_sequencer(argc, argv, &opts);\n>>>   \tif (res < 0)\n>>>   \t\tdie(_(\"revert failed\"));\n>>> +\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>>>   \treturn res;\n>>>   }\n>>>\n>>> @@ -224,11 +226,13 @@ int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n>>>   {\n>>>   \tstruct replay_opts opts = REPLAY_OPTS_INIT;\n>>>   \tint res;\n>>> +\tconst char *argv_gc_auto[] = {\"gc\", \"--auto\", NULL};\n>>>\n>>>   \topts.action = REPLAY_PICK;\n>>>   \tsequencer_init_config(&opts);\n>>>   \tres = run_sequencer(argc, argv, &opts);\n>>>   \tif (res < 0)\n>>>   \t\tdie(_(\"cherry-pick failed\"));\n>>> +\trun_command_v_opt(argv_gc_auto, RUN_GIT_CMD);\n>>>   \treturn res;\n>>>   }\n>>>\n\n"},{"id":"360176","messageId":"20181011112400.GA19800@szeder.dev","threadId":"49529","inReplyTo":"87efcwepqc.fsf@evledraar.gmail.com","subject":"Re: [PATCH] revert & cherry-pick: run git gc --auto","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-10-11T11:24:00Z","receivedAt":"2018-10-11T11:24:11Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Oct 11, 2018 at 12:34:35PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> I see we define NO_POSIX_GOODIES on Windows/MinGW, so those don't\n> demonize \"gc\", but then I'm confused by this which seems to imply the\n> opposite: https://github.com/Microsoft/vscode/issues/29901\n\nI don't think it implies that.\n\nThe last comment starts with \"Code calls git fetch periodically\".  I\npresume that it does so in the background (to prevent blocking the UI\nuntil 'git fetch' runs), therefore 'git gc --auto' starts already in\nthe background.  Furthermore, notice that 'git prune' on that\nscreenshot has two 'git.exe' parents: I think its parent is 'git gc\n--auto' and its grandparent is 'git fetch'.  Now, if that 'git gc\n--auto' were to go to the background as a result of our daemonize(),\nthen the grandparent 'git fetch' would have very likely exited\nalready.\n\n"}]}