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

>
> Arsh Srivastava <arshsrivastava00@gmail.com> writes:
>
> > 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.
> >
>
> 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]