On Sun, 2017-07-30 at 16:17 +0530, Kaartic Sivaraam wrote:
> On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote:
> > We perhaps need to somehow make sure new users won't be led to the
> > misunderstanding. Improving our documentation is a good first step.
>
> That's something I could help wi
On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
> >
> > That's interesting. In that case, I'll go with the suggested statement,
> > happily!
>
> It is not interesting at all. It actually is disturbing that you
> had the notion that these are "valid" command l
Kaartic Sivaraam writes:
> On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote:
>> Kaartic Sivaraam writes:
>>
>> > Though the message seems to be most fitting one, I'm a little reluctant
>> > to use it as it "might" create a wrong picture on the minds of the user
>> > making them think thi
On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> > Though the message seems to be most fitting one, I'm a little reluctant
> > to use it as it "might" create a wrong picture on the minds of the user
> > making them think this would be the case in other cases
Kaartic Sivaraam writes:
> Though the message seems to be most fitting one, I'm a little reluctant
> to use it as it "might" create a wrong picture on the minds of the user
> making them think this would be the case in other cases too, which we
> know is not true. For example,
>
>
> git log -
On Wed, 2017-07-26 at 13:09 -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > For an initial guess: in the example
> >
> > git grep test -n
> >
> > ...
> > 2. Focus on "argument" instead of "filename" so that the message
> > could still apply: something like
> >
> > fat
Jonathan Nieder writes:
> For an initial guess: in the example
>
> git grep test -n
>
> ...
> 2. Focus on "argument" instead of "filename" so that the message
> could still apply: something like
>
> fatal: option '-n' must come before non-option arguments
I think this one is the
Hello Jonathan Nieder,
Thanks for the reply!
Jonathan Nieder wrote:
>
> > The error message shown when a flag is found when expecting a
> > filename wasn't clear as it didn't communicate what was wrong
> > using the 'suitable' words in *all* cases.
> >
> > Correct case,
> >
> > $ git r
Hi,
Kaartic Sivaraam wrote:
> The error message shown when a flag is found when expecting a
> filename wasn't clear as it didn't communicate what was wrong
> using the 'suitable' words in *all* cases.
>
> Correct case,
>
> $ git rev-parse commit.c --flags
> commit.c
> --fl
I've added RFC to this patch's subject as I'm not sure if the new
message is suitable. Suggestions for messages that are more suitable
are welcome.
It seems that the function "verify_filename" is invoked by plumbing
commands like 'rev-parse', let me know if I've missed something about
them.
I fur
The error message shown when a flag is found when expecting a
filename wasn't clear as it didn't communicate what was wrong
using the 'suitable' words in *all* cases.
Correct case,
$ git rev-parse commit.c --flags
commit.c
--flags
fatal: bad flag '--flags' used aft
11 matches
Mail list logo
