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

Re: [PATCH v2 3/3] commit: print advice when core.commentString=auto

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Aug 26, 2025, 13:33 UTC
Message-ID
<af0c22b9-5034-4bbd-9cdd-f1f16d933e4d@gmail.com>
In-Reply-To
<aIzayan9nFZo4XYv@ugly>
On 01/08/2025 16:18, Oswald Buddenhagen wrote:
Show 14 quoted lines
> On Thu, Jul 31, 2025 at 04:21:55PM +0100, Phillip Wood wrote:
>> An alternative
>> approach would be to advise the user to run "git config --show-origin"
>> and leave them to figure out how to fix it themselves but that seems
>> rather unfriendly. As we're forcing them to update their config we
>> should try and make that as easy as possible.
>>
> your approach certainly helps the user to fix their acute problem 
> quickly, but
> - why should it? it's not like leaving it to the user would cause them a 
>    huge burden, or that a noteworthy number of users are even going to 
> be   affected. i don't think the fact that the update is forced 
> justifies   making it a lot more user friendly than git configuration 
> usually is,   esp. at this cost in complexity.

I think the fact that we're forcing the user to update does matter because it means they're having to update their config when they otherwise would not have to. I'd much rather it gave me a suggestion on how to proceed rather than told me to check my config and figure out what to do. There is certainly a complexity cost but I don't think it is that high. Some of git's reputation for being hard to use is well earned and I don't want to add to that.

> - i don't think i'd appreciate the tool lecturing me about trivial usage 
>    patterns, when the real question in that situation is why the option 
>    was set like that in the first place and whether/how the replacement 
>    is actually equivalent or even superior.

I don't think offering a suggestion is "lecturing about trivial usage patterns", I see it as offering assistance to users. The reason the advice offers two suggestions is because we cannot second guess whether the user wants to use the default or set a fixed string - it is up to them to decide.

> - given that it doesn't print the entire decision tree (when   
> encountering read-only files), it doesn't necessarily guide the user   
> towards the best overall solution. that makes it _less_ user-friendly,   
> in a way.

It provides a reasonable way of updating the config that we know will work when a user does not have write access to the system config. More experienced users are of course free to update their config as they see fit.

Thanks
Phillip
Previous: Junio C HamanoNext: Oswald Buddenhagen
Message 28 of 45 in “breaking-changes: deprecate support for core.commentChar=auto”
  1. 0/2 breaking-changes: deprecate support for core.commentChar=autoPhillip Wood, Jul 8, 2025
  2. 1/2 breaking-changes: deprecate support for core.commentString=autoPhillip Wood, Jul 8, 2025
  3. Ayush ChandekarJul 8, 2025
  4. Phillip WoodJul 9, 2025
  5. 2/2 commit: print advice when core.commentString=autoPhillip Wood, Jul 8, 2025
  6. Junio C HamanoJul 8, 2025
  7. Phillip WoodJul 9, 2025
  8. Junio C HamanoJul 9, 2025
  9. Phillip WoodJul 11, 2025
  10. Junio C HamanoJul 11, 2025
  11. Oswald BuddenhagenJul 12, 2025
  12. Junio C HamanoJul 12, 2025
  13. Junio C HamanoJul 26, 2025
  14. Phillip WoodJul 27, 2025
  15. Junio C HamanoJul 9, 2025
  16. Ayush ChandekarJul 9, 2025
  17. Phillip WoodJul 9, 2025
  18. 0/3 breaking-changes: deprecate support for core.commentChar=autoPhillip Wood, Jul 31, 2025
  19. 1/3 breaking-changes: deprecate support for core.commentString=autoPhillip Wood, Jul 31, 2025
  20. Junio C HamanoJul 31, 2025
  21. 2/3 config: warn on core.commentString=autoPhillip Wood, Jul 31, 2025
  22. Junio C HamanoJul 31, 2025
  23. Phillip WoodAug 1, 2025
  24. Oswald BuddenhagenAug 1, 2025
  25. 3/3 commit: print advice when core.commentString=autoPhillip Wood, Jul 31, 2025
  26. Oswald BuddenhagenAug 1, 2025
  27. Junio C HamanoAug 1, 2025
  28. Phillip WoodAug 26, 2025
  29. Oswald BuddenhagenAug 27, 2025
  30. Junio C HamanoAug 27, 2025
  31. Oswald BuddenhagenAug 27, 2025
  32. Junio C HamanoAug 1, 2025
  33. Phillip WoodAug 1, 2025
  34. Junio C HamanoAug 1, 2025
  35. 0/3 breaking-changes: deprecate support for core.commentChar=autoPhillip Wood, Aug 26, 2025
  36. 1/3 breaking-changes: deprecate support for core.commentString=autoPhillip Wood, Aug 26, 2025
  37. 3/3 commit: print advice when core.commentString=autoPhillip Wood, Aug 26, 2025
  38. 2/3 config: warn on core.commentString=autoPhillip Wood, Aug 26, 2025
  39. Junio C HamanoAug 26, 2025
  40. Phillip WoodAug 27, 2025
  41. Junio C HamanoAug 27, 2025
  42. 0/3 breaking-changes: deprecate support for core.commentChar=autoPhillip Wood, Aug 27, 2025
  43. 1/3 breaking-changes: deprecate support for core.commentString=autoPhillip Wood, Aug 27, 2025
  44. 2/3 config: warn on core.commentString=autoPhillip Wood, Aug 27, 2025
  45. 3/3 commit: print advice when core.commentString=autoPhillip Wood, Aug 27, 2025

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.