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

Re: [WIP] Shift rev-list enumeration from upload-pack to pack-objects

From
Nicolas Pitre <nico@cam.org>
Date
Jun 5, 2009, 16:51 UTC
Message-ID
<alpine.LFD.2.00.0906051224510.3906@xanadu.home>
In-Reply-To
<20090605054500.06A9D21C3F4@mail.utsl.gen.nz>
On Fri, 5 Jun 2009, sam@vilain.net wrote:
Show 32 quoted lines
> instead of using the internal revision walker and piping object refs
> to pack-objects this patch passes only the revs to pack-objects, which
> in turn handles both enumeration and packing.
> 
> Signed-off-by: Sam Vilain <sam@vilain.net>
> ---
>   Submitted on behalf of Nick in order to get wider feedback on this.
>   This version passes the test suite.
> 
>  upload-pack.c |   54 +++++++++++++++++++++++++++++++++++++++++++++---------
>  1 files changed, 45 insertions(+), 9 deletions(-)
> 
> diff --git a/upload-pack.c b/upload-pack.c
> index edc7861..7eda8fd 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -155,13 +155,27 @@ static void create_pack_file(void)
>  	const char *argv[10];
>  	int arg = 0;
>  
> -	rev_list.proc = do_rev_list;
> -	/* .data is just a boolean: any non-NULL value will do */
> -	rev_list.data = create_full_pack ? &rev_list : NULL;
> -	if (start_async(&rev_list))
> -		die("git upload-pack: unable to fork git-rev-list");
> -
> -	argv[arg++] = "pack-objects";
> +	/* sending rev params to pack-objects directly is great, but unfortunately pack-objects 
> +	 * has no way of turning off thin pack generation.  this would be a relatively simple 
> +	 * addition, but as we also have to deal with shallow grafts and all it's simplest to 
> +	 * just resort to piping object refs.
> +	 */
What's that?  Where did you get that?

The way to not generate a thin pack is to not specify --thin to pack-objects. If you get a thin pack without specifying --thin then this is a bug that needs to be fixed first.

Show 12 quoted lines
> +	if (!use_thin_pack) {
> +		rev_list.proc = do_rev_list;
> +		/* .data is just a boolean: any non-NULL value will do */
> +		rev_list.data = create_full_pack ? &rev_list : NULL;
> +		if (start_async(&rev_list))
> +			die("git upload-pack: unable to fork git-rev-list");
> +		
> +		argv[arg++] = "pack-objects";
> +	} else {
> +		argv[arg++] = "pack-objects";
> +		argv[arg++] = "--revs";
> +		argv[arg++] = "--include-tag";

Shouldn't this be specified only if corresponding capability was provided by the client?

Nicolas
Previous: Johannes SixtNext: Nick Edelen
Message 5 of 15 in “[WIP] Shift rev-list enumeration from upload-pack to pack-objects”
  1. sam@vilain.netJun 5, 2009
  2. Sam VilainJun 5, 2009
  3. Johannes SixtJun 5, 2009
  4. fetch-pack: close output channel after sideband demultiplexer terminatesJohannes Sixt, Jun 8, 2009
  5. Nicolas PitreJun 5, 2009
  6. Nick EdelenJun 7, 2009
  7. Nick EdelenJun 7, 2009
  8. Nicolas PitreJun 7, 2009
  9. Nick EdelenJun 7, 2009
  10. Nick EdelenJun 7, 2009
  11. Sam VilainJun 7, 2009
  12. Nicolas PitreJun 7, 2009
  13. Nick EdelenJun 7, 2009
  14. Nicolas PitreJun 8, 2009
  15. Junio C HamanoJun 8, 2009

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.