git/list[1] front-page[2] threads[3] people[4] search[5] about
wed 2026-10-07 17:29 UTC

Re: [PATCH v7] unpack-trees: suggest using 'git stash' when checkout fails

From
Arsh Srivastava <arshsrivastava00@gmail.com>
Date
Mar 13, 2026, 03:13 UTC
Message-ID
<CAOAgETMCb++MnOC9YEN+y0TE9NeVC+-=Zez7UOVY3kt8vv7dRQ@mail.gmail.com>
In-Reply-To
<xmqqldfwacyw.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes :
> The first paragraph is a bit of a run-on and has a misplaced "and";
> I cannot quite read and understand this overly long single sentence.
> Perhaps the early part can become a bit easier to read with
punctuations, and cutting the sentence into two, e.g.,

In my future commits I will remember to make it as easy to read as possible. With less punctuations and shorter sentences which will in turn make it more concise.

> Also it is misleading to say "previous" error message.  We talk
> about the current code in the present tense, to highlight what the
> problem in the current code is.

Understood I will in future not use previous because it is the _current_ code.

> You may view it as a weakness (which
> may motivate this patch to be written).  But I personally am not so
> sure that adding words to the existing message would necessarily
> make it more clear.

I understand, git wants people to not explore the available change options and help them make logical decisions rather than pushing them with some unneeded commands.

> As Documentation/SubmittingPatches says, let's instruct the code to
> "be like so" in imperative mood.  E.g., "Enhance the error
> message..." instead of "This patch enhances...".

Understood that makes sense because nevertheless it is given that I am writing the changes for this patch only.

> These were already overly long, but the updated one is way too long
> to be read on end-user's terminal.  The source lines are overly
> long, too.
That makes total sense.
> to those users who decline the advice, we now show "Please
> commit...".  That is not what !advice_enabled() should trigger, is
> it?

Thank you so much for your guidance the advice should not trigger to those who have opted not to see. My code might have misjudged this paradigm.

> Also "To move you" -> "To move your".

I thought I had fixed this typo. Seems like I didn't. I will remember to be more cautious next time.

> Also the advice lost the other possiblity of first committing the
> work in progress on the original branch before switching, yet the
> new advice message is quite wordy.

Absolutely correct this commit does narrow the users vision for exploring.

> Also, using "for safe merge" when the user is performing a
> "checkout" might be slightly confusing, even if 'stash pop' involves
> a merge under the hood.

I don't want to sound like a programmed robot but I absolutely agree with the recommendations.

> But as I already said, I think the current text may already strike
> the right balance between being clear and being concise.

Thank you so much for your valuable guidance. If it's possible I want some guidance over the questions written below, As it is well stated by you that the current text is clear enough. Should I still work on this PR from a purely GSoC perspective. Or should I start making my proposal or still work on this PR until my micro project is merged? Because I have already shown I can navigate git project which was the goal of micro projects in the first place.

On Fri, 13 Mar 2026 at 04:10, Junio C Hamano <gitster@pobox.com> wrote:
Show 101 quoted lines
>
> "Arsh Srivastava via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > When a branch switch fails due to local changes and
> > new users who are not familiar with the error message often
> > get confused about how to move ahead and resolve the issue as
> > the previous error message only suggests to commit or stash the changes
> > but doesn't explain how to do that or what the next steps are.
>
> The first paragraph is a bit of a run-on and has a misplaced "and";
> I cannot quite read and understand this overly long single sentence.
>
> Perhaps the early part can become a bit easier to read with
> punctuations, and cutting the sentence into two, e.g.,
>
>   When a branch switch fails due to local changes, new users who
>   are unfamiliar with the error message often get confused about how
>   to move ahead and resolve the issue.
>
> Also it is misleading to say "previous" error message.  We talk
> about the current code in the present tense, to highlight what the
> problem in the current code is.  The _current_ message stops at
> hinting the commands to be used without giving wordy instructions
> that are best left to manuals.  You may view it as a weakness (which
> may motivate this patch to be written).  But I personally am not so
> sure that adding words to the existing message would necessarily
> make it more clear.
>
> > This patch enhances the error message with more specific
> > instructions in a concise manner to help users understand
> > how to resolve the issue and move their local changes
> > safely to the other branch using stash.
>
> As Documentation/SubmittingPatches says, let's instruct the code to
> "be like so" in imperative mood.  E.g., "Enhance the error
> message..." instead of "This patch enhances...".
>
> By the way, the updated message seems much less concise than the
> original.
>
> >       msg = advice_enabled(ADVICE_COMMIT_BEFORE_MERGE)
> >             ? _("Your local changes to the following files would be overwritten by checkout:\n%%s"
> > -               "Please commit your changes or stash them before you switch branches.")
> > -           : _("Your local changes to the following files would be overwritten by checkout:\n%%s");
> > +               "To move you local changes safely to the other branch,\n"
> > +               "Please try 'git stash' followed by 'git checkout <branch>' followed by 'git stash pop' for safe merge."
> > +               )
> > +           : _("Your local changes to the following files would be overwritten by checkout:\n%%s"
> > +               "Please commit your changes or stash them before you switch branches.");
>
> These were already overly long, but the updated one is way too long
> to be read on end-user's terminal.  The source lines are overly
> long, too.
>
> The original was this:
>
>         msg = advice_enabled(ADVICE_COMMIT_BEFORE_MERGE)
>               ? _("Your local changes to the following files would be overwritten by checkout:\n%%s"
>                   "Please commit your changes or stash them before you switch branches.")
>               : _("Your local changes to the following files would be overwritten by checkout:\n%%s");
>
> Note that when advice is *NOT* enabled, we only gave
>
> _("Your local changes to the following files would be overwritten by checkout:\n%%s");
>
> without any "advise" in the output.  That is what !advice_enabled() means.
>
> The updated code does this:
>
>         msg = advice_enabled(ADVICE_COMMIT_BEFORE_MERGE)
>               ? _("Your local changes to the following files would be overwritten by checkout:\n%%s"
>                   "To move you local changes safely to the other branch,\n"
>                   "Please try 'git stash' followed by 'git checkout <branch>' followed by 'git stash pop' for safe merge."
>                   )
>               : _("Your local changes to the following files would be overwritten by checkout:\n%%s"
>                   "Please commit your changes or stash them before you switch branches.");
>
> to those users who decline the advice, we now show "Please
> commit...".  That is not what !advice_enabled() should trigger, is
> it?
>
> Also "To move you" -> "To move your".
>
> Also the advice lost the other possiblity of first committing the
> work in progress on the original branch before switching, yet the
> new advice message is quite wordy.
>
> Also, using "for safe merge" when the user is performing a
> "checkout" might be slightly confusing, even if 'stash pop' involves
> a merge under the hood.
>
> A more concise version might say:
>
>   Try 'git stash && git checkout <branch> && git stash pop' to carry
>   your changes to the new branch, or commit your work before switching.
>
> But as I already said, I think the current text may already strike
> the right balance between being clear and being concise.
>
> Thanks.
>
Previous: Junio C HamanoNext: Karthik Nayak
Message 56 of 62 in “Advice on checkout dirty files”
  1. 0/5 Advice on checkout dirty filesArsh Srivastava via GitGitGadget, Mar 10, 2026
  2. 1/5 diff: handle ANSI escape codes in prefix when calculating diffstat widthLorenzoPegorari via GitGitGadget, Mar 10, 2026
  3. 2/5 t4052: test for diffstat width when prefix contains ANSI escape codesLorenzoPegorari via GitGitGadget, Mar 10, 2026
  4. 3/5 repo: remove unnecessary variable shadowK Jayatheerth via GitGitGadget, Mar 10, 2026
  5. 4/5 The 13th batchJunio C Hamano via GitGitGadget, Mar 10, 2026
  6. 5/5 advice: add stashBeforeCheckout advice for dirty branch switchesArsh Srivastava via GitGitGadget, Mar 10, 2026
  7. Phillip WoodMar 10, 2026
  8. Arsh SrivastavaMar 10, 2026
  9. Arsh SrivastavaMar 10, 2026
  10. advice: add stashBeforeCheckout advice for dirty branch switchesArsh Srivastava via GitGitGadget, Mar 10, 2026
  11. Arsh SrivastavaMar 10, 2026
  12. Patrick SteinhardtMar 10, 2026
  13. 0/2 Advice on checkout dirty filesArsh Srivastava via GitGitGadget, Mar 10, 2026
  14. 1/2 advice: add stashBeforeCheckout advice for dirty branch switchesArsh Srivastava via GitGitGadget, Mar 10, 2026
  15. 2/2 advice: add stashBeforeCheckout advice for dirty branch switches [GSOC]Arsh Srivastava via GitGitGadget, Mar 10, 2026
  16. Junio C HamanoMar 10, 2026
  17. Arsh SrivastavaMar 10, 2026
  18. Arsh SrivastavaMar 10, 2026
  19. Arsh SrivastavaMar 10, 2026
  20. Patrick SteinhardtMar 10, 2026
  21. Karthik NayakMar 10, 2026
  22. Arsh SrivastavaMar 10, 2026
  23. Arsh SrivastavaMar 10, 2026
  24. Arsh SrivastavaMar 10, 2026
  25. Junio C HamanoMar 10, 2026
  26. Arsh SrivastavaMar 10, 2026
  27. Arsh SrivastavaMar 10, 2026
  28. Junio C HamanoMar 10, 2026
  29. Karthik NayakMar 10, 2026
  30. Karthik NayakMar 10, 2026
  31. Arsh SrivastavaMar 10, 2026
  32. Arsh SrivastavaMar 10, 2026
  33. 0/5 Advice on checkout dirty filesArsh Srivastava via GitGitGadget, Mar 11, 2026
  34. 1/5 advice: add stashBeforeCheckout advice for dirty branch switchesArsh Srivastava via GitGitGadget, Mar 11, 2026
  35. 2/5 advice: add stashBeforeCheckout advice for dirty branch switches [GSOC]Arsh Srivastava via GitGitGadget, Mar 11, 2026
  36. 3/5 unpack-trees: suggesting 'git checkout -m <branch>' with its repercussionsArsh Srivastava via GitGitGadget, Mar 11, 2026
  37. 4/5 Updating tests and unpack-tress.c [GSOC]Arsh Srivastava via GitGitGadget, Mar 11, 2026
  38. 5/5 File updation [GSOC]Arsh Srivastava via GitGitGadget, Mar 11, 2026
  39. Junio C HamanoMar 11, 2026
  40. Arsh SrivastavaMar 11, 2026
  41. 0/3 Advice on checkout dirty filesArsh Srivastava via GitGitGadget, Mar 11, 2026
  42. 1/3 advice: add stashBeforeCheckout advice for dirty branch switchesArsh Srivastava via GitGitGadget, Mar 11, 2026
  43. 2/3 advice: add stashBeforeCheckout advice for dirty branch switches [GSOC]Arsh Srivastava via GitGitGadget, Mar 11, 2026
  44. 3/3 unpack-trees: suggesting 'git checkout -m <branch>' with its repercussionsArsh Srivastava via GitGitGadget, Mar 11, 2026
  45. Junio C HamanoMar 12, 2026
  46. Arsh SrivastavaMar 12, 2026
  47. unpack-trees: suggesting 'git checkout -m' with its repercussionsArsh Srivastava via GitGitGadget, Mar 12, 2026
  48. Junio C HamanoMar 12, 2026
  49. Arsh SrivastavaMar 12, 2026
  50. Junio C HamanoMar 12, 2026
  51. Arsh SrivastavaMar 12, 2026
  52. Junio C HamanoMar 12, 2026
  53. Arsh SrivastavaMar 12, 2026
  54. unpack-trees: suggest using 'git stash' when checkout failsArsh Srivastava via GitGitGadget, Mar 12, 2026
  55. Junio C HamanoMar 12, 2026
  56. Arsh SrivastavaMar 13, 2026
  57. Karthik NayakMar 13, 2026
  58. Arsh SrivastavaMar 13, 2026
  59. Arsh SrivastavaMar 13, 2026
  60. Arsh SrivastavaMar 13, 2026
  61. Junio C HamanoMar 13, 2026
  62. Konstantin RyabitsevMar 14, 2026

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.