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
Taylor Blau <me@ttaylorr.com>
Date
May 24, 2022, 21:33 UTC
Message-ID
<Yo1PRKUGgIyeDGKp@nand.local>
In-Reply-To
<220524.86zgj6vhge.gmgdl@evledraar.gmail.com>
On Tue, May 24, 2022 at 09:46:09PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 51 quoted lines
>
> On Tue, May 24 2022, Taylor Blau wrote:
>
> > -	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?

This is intentional. OBJ_NONE tells create_object_entry() "we don't know the type of this object yet", and then `check_object()` (which does the bulk of the work in the "Counting objects" phase) goes through and fills in any missing type information.

The caller in `builtin/pack-objects.c::read_object_list_from_stdin()` is a good example of this (all of the objects created this way start out with OBJ_NONE).

Show 41 quoted lines
> 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"?

I'd be fine with that (and don't really have a very strong opinion either way). Let's see if anybody else has thoughts about it, and then I'm happy to change it in a subsequent version.

Thanks, Taylor

Previous: Ævar Arnfjörð BjarmasonNext: Ævar Arnfjörð Bjarmason
Message 21 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.