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

Re: [PATCH v2 3/4] builtin/pack-objects.c: ensure included `--stdin-packs` exist

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
May 24, 2022, 19:46 UTC
Message-ID
<220524.86zgj6vhge.gmgdl@evledraar.gmail.com>
In-Reply-To
<cdc3265ec27f04accc433d9e4e54ac0edc3b3746.1653418457.git.me@ttaylorr.com>
On Tue, May 24 2022, Taylor Blau wrote:
Show 44 quoted lines
> -	struct rev_info *revs = _data;
> -	struct object_info oi = OBJECT_INFO_INIT;
>  	off_t ofs;
> -	enum object_type type;
> +	enum object_type type = OBJ_NONE;
>  
>  	display_progress(progress_state, ++nr_seen);
>  
> @@ -3215,20 +3213,25 @@ static int add_object_entry_from_pack(const struct object_id *oid,
>  	if (!want_object_in_pack(oid, 0, &p, &ofs))
>  		return 0;
>  
> -	oi.typep = &type;
> -	if (packed_object_info(the_repository, p, ofs, &oi) < 0)
> -		die(_("could not get type of object %s in pack %s"),
> -		    oid_to_hex(oid), p->pack_name);
> -	else if (type == OBJ_COMMIT) {
> -		/*
> -		 * commits in included packs are used as starting points for the
> -		 * subsequent revision walk
> -		 */
> -		add_pending_oid(revs, NULL, oid, 0);
> +	if (p) {
> +		struct rev_info *revs = _data;
> +		struct object_info oi = OBJECT_INFO_INIT;
> +
> +		oi.typep = &type;
> +		if (packed_object_info(the_repository, p, ofs, &oi) < 0) {
> +			die(_("could not get type of object %s in pack %s"),
> +			    oid_to_hex(oid), p->pack_name);
> +		} else if (type == OBJ_COMMIT) {
> +			/*
> +			 * commits in included packs are used as starting points for the
> +			 * subsequent revision walk
> +			 */
> +			add_pending_oid(revs, NULL, oid, 0);
> +		}
> +
> +		stdin_packs_found_nr++;
>  	}
>  
> -	stdin_packs_found_nr++;
> -
>  	create_object_entry(oid, type, 0, 0, 0, p, ofs);

Not rhetorical, since I have no idea: Is the behavior change here to make create_object_entry with type=OBJ_NONE desired? I.e. do we actually want to create object entries for OBJ_NONE?

If that is the case I for one would find this a bit easier to follow
like this, even if it has some minor duplication, i.e. the intent is
clearer:
	
	diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
	index ffeaecd1d84..a447f6d5164 100644
	--- a/builtin/pack-objects.c
	+++ b/builtin/pack-objects.c
	@@ -3202,7 +3202,6 @@ static int add_object_entry_from_pack(const struct object_id *oid,
	 				      void *_data)
	 {
	 	off_t ofs;
	-	enum object_type type = OBJ_NONE;
	 
	 	display_progress(progress_state, ++nr_seen);
	 
	@@ -3216,6 +3215,7 @@ static int add_object_entry_from_pack(const struct object_id *oid,
	 	if (p) {
	 		struct rev_info *revs = _data;
	 		struct object_info oi = OBJECT_INFO_INIT;
	+		enum object_type type;
	 
	 		oi.typep = &type;
	 		if (packed_object_info(the_repository, p, ofs, &oi) < 0) {
	@@ -3230,9 +3230,11 @@ static int add_object_entry_from_pack(const struct object_id *oid,
	 		}
	 
	 		stdin_packs_found_nr++;
	-	}
	 
	-	create_object_entry(oid, type, 0, 0, 0, p, ofs);
	+		create_object_entry(oid, type, 0, 0, 0, p, ofs);
	+	} else  {
	+		create_object_entry(oid, OBJ_NONE, 0, 0, 0, p, ofs);
	+	}
	 
	 	return 0;
	 }

Or the same with adding "type = OBJ_NONE" to the "else" branch, leaving the initial "type" uninitialized"?

Or perhaps this is a bug? I see some OBJ_NONE mentions in the code, but do packfiles really have "none" objects in some fashion as far as add_object_entry_from_pack() is concerned? (I'm not familiar enough with this part of the codebase to know).

Previous: Taylor BlauNext: Taylor Blau
Message 20 of 29 in “pack-objects: fix a pair of MIDX bitmap-related races”
  1. 0/2 pack-objects: fix a pair of MIDX bitmap-related racesTaylor Blau, May 13, 2022
  2. 1/2 pack-bitmap: check preferred pack validity when opening MIDX bitmapTaylor Blau, May 13, 2022
  3. Junio C HamanoMay 13, 2022
  4. Taylor BlauMay 13, 2022
  5. 2/2 builtin/pack-objects.c: ensure pack validity from MIDX bitmap objectsTaylor Blau, May 13, 2022
  6. Jonathan TanMay 13, 2022
  7. Taylor BlauMay 14, 2022
  8. Jonathan TanMay 16, 2022
  9. Taylor BlauMay 14, 2022
  10. Jonathan TanMay 16, 2022
  11. 0/4 pack-objects: fix a pair of MIDX bitmap-related racesTaylor Blau, May 24, 2022
  12. 1/4 pack-bitmap.c: check preferred pack validity when opening MIDX bitmapTaylor Blau, May 24, 2022
  13. Ævar Arnfjörð BjarmasonMay 24, 2022
  14. Taylor BlauMay 24, 2022
  15. Ævar Arnfjörð BjarmasonMay 24, 2022
  16. 2/4 builtin/pack-objects.c: avoid redundant NULL checkTaylor Blau, May 24, 2022
  17. Junio C HamanoMay 24, 2022
  18. Taylor BlauMay 25, 2022
  19. 3/4 builtin/pack-objects.c: ensure included `--stdin-packs` existTaylor Blau, May 24, 2022
  20. Ævar Arnfjörð BjarmasonMay 24, 2022
  21. Taylor BlauMay 24, 2022
  22. Ævar Arnfjörð BjarmasonMay 24, 2022
  23. Junio C HamanoMay 24, 2022
  24. Taylor BlauMay 25, 2022
  25. Victoria DyeMay 26, 2022
  26. Taylor BlauMay 26, 2022
  27. 4/4 builtin/pack-objects.c: ensure pack validity from MIDX bitmap objectsTaylor Blau, May 24, 2022
  28. Junio C HamanoMay 24, 2022
  29. Taylor BlauMay 25, 2022

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.