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

Re: [PATCH] setup: warn about un-enabled extensions

From
Derrick Stolee <stolee@gmail.com>
Date
Jul 14, 2020, 15:40 UTC
Message-ID
<18c65b85-2f2a-ff96-1ea7-e16befa6928f@gmail.com>
In-Reply-To
<xmqqzh82ktgm.fsf@gitster.c.googlers.com>
On 7/14/2020 11:27 AM, Junio C Hamano wrote:
Show 40 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>>> If you don't mind, I was already going to squash Junio's commit into
>>> mine (almost completely replacing mine) but I could add a small
>>> commit on top that provides the following improvement to the error
>>> message:
>>
>> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing
>> users in the same was as v2.28.0-rc0 confused me.
> 
> In a nearby thread, Jonathan Nieder raised an interesting approach
> to avoid confusing users, which I think (if I am reading him
> correctly) makes sense (cf. <20200714040616.GA2208896@google.com>)
> 
> What if we accept the extensions the code before the topic in
> question that was merged in -rc0 introduced the "confusion" accepts
> even in v0?  If we see extensions other than those handpicked and
> grandfathered ones (which are presumably the ones we add later and
> support in v1 and later repository versions) in a v0 repository, we
> keep ignoring.  Also we'd loosen the overly strict code that
> prevents upgrading from v0 to v1 in the presence of any extensions
> in -rc0, so that the grandfathered ones will not prevent the
> upgrading.
> 
> The original reasoning behind the strict check was because the users
> could have used extensions.frotz for their own use with their own
> meaning, trusting that Git would simply ignore it, and an upgrade to
> later version in which Git uses extensions.frotz for a purpose that
> is unrelated to the reason why these users used would just break the
> repository.  
> 
> But the ones that were (accidentally) honored in v0 couldn't have
> been used by the users for the purposes other than how Git would use
> them anyway, so there is no point to make them prevent the upgrade
> of the repository version from v0 to v1.
> 
> At least, that is how I understood the world would look like in
> Jonathan's "different endgame".
> 
> What do you three (Dscho, Derrick and Jonathan) think?  

If "v0" includes "core.repositoryFormatVersion is unset" then I would consider this to be a way to avoid all user pain, which is positive.

I'd be happy to test and review a patch that accomplishes this goal.

CC'ing Ed Thomson because this extension stuff affects other tools, like libgit2.

Thanks, -Stolee

Previous: Junio C HamanoNext: Johannes Schindelin
Message 6 of 39 in “setup: warn about un-enabled extensions”
  1. setup: warn about un-enabled extensionsJohannes Schindelin via GitGitGadget, Jul 13, 2020
  2. Junio C HamanoJul 13, 2020
  3. Derrick StoleeJul 14, 2020
  4. Johannes SchindelinJul 14, 2020
  5. Junio C HamanoJul 14, 2020
  6. Derrick StoleeJul 14, 2020
  7. Johannes SchindelinJul 14, 2020
  8. Junio C HamanoJul 14, 2020
  9. Junio C HamanoJul 15, 2020
  10. Junio C HamanoJul 15, 2020
  11. Derrick StoleeJul 15, 2020
  12. Junio C HamanoJul 15, 2020
  13. Derrick StoleeJul 15, 2020
  14. Johannes SchindelinJul 15, 2020
  15. Junio C HamanoJul 15, 2020
  16. Johannes SchindelinJul 15, 2020
  17. Jonathan NiederJul 15, 2020
  18. Junio C HamanoJul 16, 2020
  19. 0/2 extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions)Jonathan Nieder, Jul 16, 2020
  20. 1/2 Revert "check_repository_format_gently(): refuse extensions for old repositories"Jonathan Nieder, Jul 16, 2020
  21. Jeff KingJul 16, 2020
  22. 2/2 repository: allow repository format upgrade with extensionsJonathan Nieder, Jul 16, 2020
  23. Junio C HamanoJul 16, 2020
  24. Jeff KingJul 16, 2020
  25. Jeff KingJul 16, 2020
  26. Derrick StoleeJul 16, 2020
  27. Junio C HamanoJul 16, 2020
  28. Jeff KingJul 16, 2020
  29. Junio C HamanoJul 16, 2020
  30. Junio C HamanoJul 16, 2020
  31. Jeff KingJul 16, 2020
  32. Junio C HamanoJul 16, 2020
  33. Jonathan NiederJul 16, 2020
  34. Junio C HamanoJul 16, 2020
  35. Jeff KingJul 17, 2020
  36. Junio C HamanoJul 17, 2020
  37. Jeff KingJul 17, 2020
  38. Johannes SchindelinJul 16, 2020
  39. Derrick StoleeJul 16, 2020

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.