From: Karthik Nayak Date: Fri, 13 Mar 2026 10:43:11 GMT Subject: Re: [PATCH v7] unpack-trees: suggest using 'git stash' when checkout fails Message-ID: In-Reply-To: Arsh Srivastava writes: > Junio C Hamano 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. > From the micro-project information [1] for GSoC we have: The coding part of the microproject should be very small (say, 10-30 minutes). We don’t require that your patch be accepted into the “master” branch by the time of your formal application; we mostly want to see that you have a basic level of competence and especially the ability to interact with the other Git developers. As such and seeing Junio's previous response, I would say that no further work is required here. [1]: https://git.github.io/General-Microproject-Information/ [snip]