Junio C Hamano venit, vidit, dixit 24.07.2014 23:30:
> Duy Nguyen <pclo...@gmail.com> writes:
>> On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber
>> <g...@drmicha.warpmail.net> wrote:
>>> Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.07.2014 13:43:
>>>> + if (advice_checkout_to)
>>>> + die(_("%s is already checked out at %s.\n"
>>>> + "Either use --detach or -b together with --to "
>>>> + "or switch branch in the the other checkout."),
>>> "or switch to a different branch in the other checkout". But maybe we
>>> can be even more helpful, like:
>>> "%s is already checked out at %s.\n"
>>> "Either checkout the detached head of branch %s using\n"
>>> " git checkout --detach --to %s %s\n"
>>> "or checkout a new branch based off %s using\n"
>>> " git checkout --to %s -b %s newbranch %s\n"
>>> "or switch to a different branch in the other checkout."
>>> if we can figure out the appropriate arguments at this point in the code.
>> We would not be able to construct the exact command that the user has
>> entered, so perhaps
>> git checkout --detach <more options> %s
>> git checkout -b <new branch> <more options> %s
>> Note that this does not only occur when --to is given. If you have two
>> checkouts associated to the same repo, "git checkout foo" on one
>> checkout when "foo" is held by another checkout would cause the same
>> error. I'll need to think of a better name than advice.checkoutTo.
> I am not sure if we need to say anything more than the first line of
> the message you have in your patch. To fork a new branch at the
> commit the user is interested in to check it out, or not bothering
> with the branch and detach, are both very normal parts of user's Git
> toolchest, nothing particularly special. As long as the most
> important point, i.e. "in the new world order, unlike the
> contrib/workdir hack, you cannot check out the same branch at two
> different places", is clearly conveyed and understood, everything
> else should follow naturally, no?
As an error message that is completely sufficient.
The advice messages are meant to teach the user about the normal parts
of the toolchest to use in a situation of "conflict", aren't they? Maybe
we should ask someone who hasn't turned them off...
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html