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

Re: [PATCH v2 2/3] setup: do not use invalid `repository_format`

From
MÅMartin Ågren <martin.agren@gmail.com>
Date
Jan 17, 2019, 06:31 UTC
Message-ID
<20190117063114.1901775-1-martin.agren@gmail.com>
In-Reply-To
<20190115193112.GE4886@sigill.intra.peff.net>
On Tue, 15 Jan 2019 at 20:31, Jeff King <peff@peff.net> wrote:
Show 10 quoted lines
>
> On Mon, Jan 14, 2019 at 07:34:56PM +0100, Martin Ågren wrote:
>
> > This can be observed by adding this to the end of
> > `read_repository_format()`:
> >
> >       if (format->version == -1)
> >               format->hash_algo = 0; /* no-one should peek at this! */
> >
> > Check that `version` is non-negative before using `hash_algo`.
Show 20 quoted lines
> I'm still somewhat confused about how this breaks. If we move
> ".git/config" out of the way, then we have no version indicator and
> presumably we should guess GIT_HASH_SHA1. Which is what's happening if
> we fail to call repo_set_hash_algo(), no?  In other words, wouldn't
> repo_set_hash_algo() always be a noop in that case?
>
> I get why adding the code snippet above would cause that assumption to
> break, but I am just not sure why we would add that code snippet. ;)
>
> I also get why read_repository_format() doing this in patch 3 would be a
> problem:
>
>   +       if (format->version == -1) {
>   +               clear_repository_format(format);
>   +               format->version = -1;
>   +       }
>
> but doesn't that point out that clear_repository_format() should be
> setting hash_algo to GIT_HASH_SHA1 as the default (and likewise "bare =
> -1", etc, that is done in that function)?

Something like the below on top of this series (then rebased). (The last hunk below is a revert of this patch.)

I'd like to think of the situation before this patch above as a situation where the API promises something and the user uses the API beyond that. The next patch in this series changes the internals of the API in a way that is consistent with the promise made, but which ends up affecting an over-eager user.

What this patch above does is to make the user do what the API promise allows them to do, i.e., no more shortcuts. What you're saying is, why isn't the promise stronger? So the user won't have to think as much?

So in particular, why doesn't `clear...()` and the error path in `read_...()` impose sane, usable defaults? My first concern is that it means we need to make a stronger promise, which might then be hard to back away from, if we want to. Maybe we'll never want to...

My second concern is, what should we be falling back to, going forward? At some point, the hash indicated by `REPOSITORY_FORMAT_INIT` will be SHA-256. Before that, and as soon as we support both hashes, what if we pick up SHA-256 before stumbling on some other piece of the config -- should we now reset the struct to indicate SHA-1, or rather keep the SHA-256 value, which by itself is valid? (The same could be argued now, for something other than hash functions, but the SHA-1/256 example might be more obvious in the context of this patch.)

My third worry is that we should then equip `clear_...()` or at least the error path of `read_...()` with some logic to keep "as much as possible" of what we've picked up and reset the rest, all the while making sure we don't end up with something self-contradicting or stupid. After all, we'll have promised the users that they can ignore any errors and just run ahead.

Maybe I'm worrying way too much, and I shouldn't be so afraid of making a stronger promise here and now because of vague slippery-slope thinking.

Thanks for pushing back and forcing me to articulate my thinking.
Martin
diff --git a/cache.h b/cache.h
index 3ef63d27c4..acd86e9f9f 100644
--- a/cache.h
+++ b/cache.h
@@ -974,15 +974,21 @@ struct repository_format {
 
 /**
  * Always use this to initialize a `struct repository_format`
- * to a well-defined state before calling `read_repository()`.
+ * to a well-defined, default state before calling
+ * `read_repository()`.
  */
-#define REPOSITORY_FORMAT_INIT { 0 }
+#define REPOSITORY_FORMAT_INIT (struct repository_format){ \
+				 .version = -1, \
+				 .is_bare = -1, \
+				 .hash_algo = GIT_HASH_SHA1, \
+				 .unknown_extensions = STRING_LIST_INIT_DUP, \
+			       }
 
 /*
  * Read the repository format characteristics from the config file "path" into
  * "format" struct. Returns the numeric version. On error, -1 is returned,
  * format->version is set to -1, and all other fields in the struct are
- * undefined.
+ * set to the default configuration (REPOSITORY_FORMAT_INIT).
  */
 int read_repository_format(struct repository_format *format, const char *path);
 
diff --git a/setup.c b/setup.c
index 70d9007ae5..f3ea479ad9 100644
--- a/setup.c
+++ b/setup.c
@@ -511,15 +511,9 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
 int read_repository_format(struct repository_format *format, const char *path)
 {
 	clear_repository_format(format);
-	format->version = -1;
-	format->is_bare = -1;
-	format->hash_algo = GIT_HASH_SHA1;
-	string_list_init(&format->unknown_extensions, 1);
 	git_config_from_file(check_repo_format, path, format);
-	if (format->version == -1) {
+	if (format->version == -1)
 		clear_repository_format(format);
-		format->version = -1;
-	}
 	return format->version;
 }
 
@@ -528,7 +522,7 @@ void clear_repository_format(struct repository_format *format)
 	string_list_clear(&format->unknown_extensions, 0);
 	free(format->work_tree);
 	free(format->partial_clone);
-	memset(format, 0, sizeof(*format));
+	*format = REPOSITORY_FORMAT_INIT;
 }
 
 int verify_repository_format(const struct repository_format *format,
@@ -1152,7 +1146,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
 				gitdir = DEFAULT_GIT_DIR_ENVIRONMENT;
 			setup_git_env(gitdir);
 		}
-		if (startup_info->have_repository && repo_fmt.version > -1)
+		if (startup_info->have_repository)
 			repo_set_hash_algo(the_repository, repo_fmt.hash_algo);
 	}
 
Previous: Jeff KingNext: Jeff King
Message 23 of 40 in “setup: add `clear_repository_format()`”
  1. 0/3 setup: add `clear_repository_format()`Martin Ågren, Dec 18, 2018
  2. 1/3 setup: drop return value from `read_repository_format()`Martin Ågren, Dec 18, 2018
  3. Jeff KingDec 19, 2018
  4. Martin ÅgrenDec 19, 2018
  5. brian m. carlsonDec 20, 2018
  6. Jeff KingDec 20, 2018
  7. brian m. carlsonDec 20, 2018
  8. Jeff KingDec 20, 2018
  9. 2/3 setup: do not use invalid `repository_format`Martin Ågren, Dec 18, 2018
  10. brian m. carlsonDec 19, 2018
  11. Martin ÅgrenDec 19, 2018
  12. Jeff KingDec 19, 2018
  13. Martin ÅgrenDec 19, 2018
  14. Jeff KingDec 19, 2018
  15. brian m. carlsonDec 20, 2018
  16. 3/3 setup: add `clear_repository_format()`Martin Ågren, Dec 18, 2018
  17. Jeff KingDec 19, 2018
  18. Martin ÅgrenDec 19, 2018
  19. 0/3 setup: add `clear_repository_format()`Martin Ågren, Jan 14, 2019
  20. 1/3 setup: free old value before setting `work_tree`Martin Ågren, Jan 14, 2019
  21. 2/3 setup: do not use invalid `repository_format`Martin Ågren, Jan 14, 2019
  22. Jeff KingJan 15, 2019
  23. Martin ÅgrenJan 17, 2019
  24. Jeff KingJan 22, 2019
  25. Martin ÅgrenJan 22, 2019
  26. 0/2 setup: fix memory leaks with `struct repository_format`Martin Ågren, Jan 22, 2019
  27. 1/2 setup: free old value before setting `work_tree`Martin Ågren, Jan 22, 2019
  28. 2/2 setup: fix memory leaks with `struct repository_format`Martin Ågren, Jan 22, 2019
  29. Jeff KingJan 23, 2019
  30. brian m. carlsonJan 24, 2019
  31. Martin ÅgrenJan 25, 2019
  32. Martin ÅgrenJan 25, 2019
  33. Jeff KingJan 25, 2019
  34. Martin ÅgrenFeb 25, 2019
  35. Jeff KingFeb 26, 2019
  36. 0/2 setup: fix memory leaks with `struct repository_format`Martin Ågren, Feb 28, 2019
  37. 1/2 setup: free old value before setting `work_tree`Martin Ågren, Feb 28, 2019
  38. 2/2 setup: fix memory leaks with `struct repository_format`Martin Ågren, Feb 28, 2019
  39. Jeff KingMar 6, 2019
  40. 3/3 setup: add `clear_repository_format()`Martin Ågren, Jan 14, 2019

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.