git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Phillip Wood <phillip.wood@talktalk.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, phillip.wood@dunelm.org.uk
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>
Subject: Re: [PATCH] revert & cherry-pick: run git gc --auto
Date: Thu, 11 Oct 2018 12:14:31 +0100	[thread overview]
Message-ID: <65275c82-1fc0-8f89-8c13-562b73f3ffcf@talktalk.net> (raw)
In-Reply-To: <87ftxceqxc.fsf@evledraar.gmail.com>

Hi Ævar
On 11/10/2018 11:08, Ævar Arnfjörð Bjarmason wrote:
> 
> On Thu, Oct 11 2018, Phillip Wood wrote:
> 
>> Hi Ævar
>>
>> On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:
>>> Expand on the work started in 095c741edd ("commit: run git gc --auto
>>> just before the post-commit hook", 2018-02-28) to run "gc --auto" in
>>> more commands where new objects can be created.
>>>
>>> The notably missing commands are now "rebase" and "stash". Both are
>>> being rewritten in C, so any use of "gc --auto" there can wait for
>>> that.
>>
>> If cherry-pick, revert or 'rebase -i' edit the commit message then they
>> fork 'git commit' so gc --auto will be run there anyway.
> 
> Yeah it seems I totally screwed up the testing for this patch, first it
> doesn't even compile because I'm not including run-command.h, I *did*
> fix that, but while wrangling a few things didn't commit that *sigh*.
> 
> And yeah, there's some invocations where we now run gc --auto twice,
> i.e. if you do revert, but not revert --no-edit, and not on cherry-pick,
> but on cherry-pick --edit.
> 
> So yeah, this really needs to be re-thought.
> 
>> I wonder if it would be better to call 'gc --auto' from sequencer.c at
>> the end of a string of successful picks, that would cover cherry-pick,
>> 'rebase -iu' and revert. With 'rebase -i' it might be nice to avoid
>> calling 'gc --auto' until the very end, rather than every time we stop
>> for an edit but that is probably more trouble than it is worth.
> 
> That seems a lot better indeed. I.e. running it from the sequencer. I do
> wonder if there should be some smarts about running it in the middle of
> a sequence, i.e. think of a case where we're rebasing 10k commits, which
> is a gc need similar to what happens in the middle of "git svn
> clone". So maybe something where we gc --auto in the sequencer for every
> Nth commit, and at the end.

That sounds like a good idea. It would be nice if need_to_gc() was in 
libgit, then we could avoid the cost of forking unless we actually need 
to gc. Looking at builtin/gc.c there seem to be quite a few global 
variables so transforming it to library code may not be that straight 
forward.

Best Wishes

Phillip

>>
>>>
>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>> ---
>>>
>>> After reading the "Users are encouraged to run this task..." paragraph
>>> in the git-gc manpage I was wondering if due to gc --auto all over the
>>> place now (including recently in git-commit with a patch of mine) if
>>> we shouldn't change that advice.
>>>
>>> I'm meaning to send some doc changes to git-gc.txt, but in the
>>> meantime let's address this low-hanging fruit of running gc --auto
>>> when we revert or cherry-pick commits, which can like git-commit
>>> create a significant amount of loose objects.
>>>
>>>   builtin/revert.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/builtin/revert.c b/builtin/revert.c
>>> index 9a66720cfc..1b20902910 100644
>>> --- a/builtin/revert.c
>>> +++ b/builtin/revert.c
>>> @@ -209,6 +209,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)
>>>   {
>>>   	struct replay_opts opts = REPLAY_OPTS_INIT;
>>>   	int res;
>>> +	const char *argv_gc_auto[] = {"gc", "--auto", NULL};
>>>
>>>   	if (isatty(0))
>>>   		opts.edit = 1;
>>> @@ -217,6 +218,7 @@ int cmd_revert(int argc, const char **argv, const char *prefix)
>>>   	res = run_sequencer(argc, argv, &opts);
>>>   	if (res < 0)
>>>   		die(_("revert failed"));
>>> +	run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
>>>   	return res;
>>>   }
>>>
>>> @@ -224,11 +226,13 @@ int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
>>>   {
>>>   	struct replay_opts opts = REPLAY_OPTS_INIT;
>>>   	int res;
>>> +	const char *argv_gc_auto[] = {"gc", "--auto", NULL};
>>>
>>>   	opts.action = REPLAY_PICK;
>>>   	sequencer_init_config(&opts);
>>>   	res = run_sequencer(argc, argv, &opts);
>>>   	if (res < 0)
>>>   		die(_("cherry-pick failed"));
>>> +	run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
>>>   	return res;
>>>   }
>>>


      parent reply	other threads:[~2018-10-11 11:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 19:35 [PATCH] revert & cherry-pick: run git gc --auto Ævar Arnfjörð Bjarmason
2018-10-11  9:23 ` Phillip Wood
2018-10-11 10:08   ` Ævar Arnfjörð Bjarmason
2018-10-11 10:25     ` SZEDER Gábor
2018-10-11 10:34       ` Ævar Arnfjörð Bjarmason
2018-10-11 11:24         ` SZEDER Gábor
2018-10-11 11:14     ` Phillip Wood [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65275c82-1fc0-8f89-8c13-562b73f3ffcf@talktalk.net \
    --to=phillip.wood@talktalk.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).