git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/2] maintenance: add pack-refs task

From
Derrick Stolee <stolee@gmail.com>
Date
Feb 9, 2021, 12:42 UTC
Message-ID
<f8df68ee-32a9-4bd1-99d9-4641b582992d@gmail.com>
In-Reply-To
<YCHA991dv0V0hNb+@nand.local>
On 2/8/2021 5:53 PM, Taylor Blau wrote:
Show 10 quoted lines
> On Mon, Feb 08, 2021 at 02:52:22PM +0000, Derrick Stolee via GitGitGadget wrote:
>> +pack-refs::
>> +	The `pack-refs` task collects the loose reference files and
>> +	collects them into a single file. This speeds up operations that
>> +	need to iterate across many refereences. See linkgit:git-pack-refs[1]
>> +	for more information.
>> +
> 
> Do you think it's worth documenting here or in git-gc(1) that running
> this has the effect of disabling the same step during gc?
It doesn't disable the step during gc.

Perhaps I should use a better term than "extract". The 'gc' task shouldn't change as we make some of its steps also available as independent tasks.

Instead, users can select a subset of its steps by enabling them directly. Other such tasks could include:

 * prune-reflog
 * full-repack (as opposed to the existing incremental-repack task)
Show 5 quoted lines
>> +struct maintenance_run_opts;
>> +static int maintenance_task_pack_refs(struct maintenance_run_opts *opts)
> 
> It may be worth calling this "unused", since you explicitly pass NULL
> below.
Good idea.
Show 6 quoted lines
>> +	if (pack_refs && maintenance_task_pack_refs(NULL))
>> +		die(FAILED_RUN, "pack-refs");
> 
> Hmm. Am I missing where opting into the maintenance step disables this
> in gc? You suggest that it does in the commit message, but I can't seem
> to see it here.
My commit message suggests wrong.
 
Show 10 quoted lines
>> +test_expect_success 'pack-refs task' '
>> +	for n in $(test_seq 1 5)
>> +	do
>> +		git branch -f to-pack/$n HEAD || return 1
>> +	done &&
>> +	git maintenance run --task=pack-refs &&
>> +	ls .git/refs/heads/ >after &&
>> +	test_must_be_empty after
> 
> Worth testing that $GIT_DIR/packed-refs exists, too?

That would start breaking if we change the backing store, right? I want to be sure this doesn't create test breakages with reftable.

I _could_ add a 'test_subcommand' check here, though.

Thanks, -Stolee

Previous: Taylor BlauNext: Eric Sunshine
Message 5 of 12 in “Maintenance: add pack-refs task”
  1. 0/2 Maintenance: add pack-refs taskDerrick Stolee via GitGitGadget, Feb 8, 2021
  2. 2/2 maintenance: incremental strategy runs pack-refs weeklyDerrick Stolee via GitGitGadget, Feb 8, 2021
  3. 1/2 maintenance: add pack-refs taskDerrick Stolee via GitGitGadget, Feb 8, 2021
  4. Taylor BlauFeb 8, 2021
  5. Derrick StoleeFeb 9, 2021
  6. Eric SunshineFeb 8, 2021
  7. Derrick StoleeFeb 9, 2021
  8. Taylor BlauFeb 8, 2021
  9. 0/2 Maintenance: add pack-refs taskDerrick Stolee via GitGitGadget, Feb 9, 2021
  10. 1/2 maintenance: add pack-refs taskDerrick Stolee via GitGitGadget, Feb 9, 2021
  11. 2/2 maintenance: incremental strategy runs pack-refs weeklyDerrick Stolee via GitGitGadget, Feb 9, 2021
  12. Taylor BlauFeb 10, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.