[BUG] --bare is ignored before command word

[BUG] --bare is ignored before command word

[Ronny Borchert]

I was trying to clone a bare repository. Not sure why I did, maybe
description on website was wrong.
My try:

git --bare clone https://github.....

This was leading in creating a none bare repository! No error or warning
message here!
I guess this behavior is also for other --xxx commands.

Re: [BUG] --bare is ignored before command word

[Jacob Keller]

On Wed, Nov 18, 2015 at 9:20 AM, Ronny Borchert <mister_rs@web.de> wrote:
> I was trying to clone a bare repository. Not sure why I did, maybe
> description on website was wrong.
> My try:
>
> git --bare clone https://github.....
>
> This was leading in creating a none bare repository! No error or warning
> message here!
> I guess this behavior is also for other --xxx commands.
>

This is how the git options work. Options before a command word are
always ignored. It may be better to warn about these options though,
so that they don't cause errors? The reasoning this is done is because
options between git and its command word are used to modify general
git behavior, while options after the command word modify each
specific command in their own way.

Regards,
Jake

Re: [BUG] --bare is ignored before command word

[Matthieu Moy]

Jacob Keller <jacob.keller@gmail.com> writes:

> On Wed, Nov 18, 2015 at 9:20 AM, Ronny Borchert <mister_rs@web.de> wrote:
>> I was trying to clone a bare repository. Not sure why I did, maybe
>> description on website was wrong.
>> My try:
>>
>> git --bare clone https://github.....
>>
>> This was leading in creating a none bare repository! No error or warning
>> message here!
>> I guess this behavior is also for other --xxx commands.
>>
>
> This is how the git options work. Options before a command word are
> always ignored.

No, they are not ignored. For example

$ git --foobar init
Unknown option: --foobar

=> the option is processed, and rejected explicitly.

But as you say, options before the command word apply to "git", not to
the particular command. The case of --bare is a bit unfortunate: both
"git" and "git clone" accept a --bare option, with a different meaning
(read "man git" to find what the first does).

So, I wouldn't call the current behavior a really good one, but it's the
documented behavior.

It would be nice to warn in this case though: I don't see any use for
"git --bare clone".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [BUG] --bare is ignored before command word

[Jeff King]

On Wed, Nov 18, 2015 at 10:29:20PM +0100, Matthieu Moy wrote:

> But as you say, options before the command word apply to "git", not to
> the particular command. The case of --bare is a bit unfortunate: both
> "git" and "git clone" accept a --bare option, with a different meaning
> (read "man git" to find what the first does).
> 
> So, I wouldn't call the current behavior a really good one, but it's the
> documented behavior.
> 
> It would be nice to warn in this case though: I don't see any use for
> "git --bare clone".

We have a similar situation for "git init". Once upon a time there was
just "git --bare init", and then 74d3b23 (git-init: accept --bare
option, 2008-05-28) let us do it either way.

I'm tempted to say that "git --bare clone" should work the same way.
Both init and clone are special in that they are always about creating a
new repository, not working in an existing one.  That's technically a
non-compatible behavior change, but AFAICT with the current code the
option is silently ignored, which just seems buggy.

But perhaps I am missing some useful effect it does have.

I'd also be OK with simply flagging it as useless and issuing a warning
or error.

-Peff

Re: [BUG] --bare is ignored before command word

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Wed, Nov 18, 2015 at 10:29:20PM +0100, Matthieu Moy wrote:
>
>> But as you say, options before the command word apply to "git", not to
>> the particular command. The case of --bare is a bit unfortunate: both
>> "git" and "git clone" accept a --bare option, with a different meaning
>> (read "man git" to find what the first does).
>> 
>> So, I wouldn't call the current behavior a really good one, but it's the
>> documented behavior.
>> 
>> It would be nice to warn in this case though: I don't see any use for
>> "git --bare clone".
>
> We have a similar situation for "git init". Once upon a time there was
> just "git --bare init", and then 74d3b23 (git-init: accept --bare
> option, 2008-05-28) let us do it either way.
>
> I'm tempted to say that "git --bare clone" should work the same way.
> Both init and clone are special in that they are always about creating a
> new repository, not working in an existing one.  That's technically a
> non-compatible behavior change, but AFAICT with the current code the
> option is silently ignored, which just seems buggy.

I agree with this. I can't see a real use-case "git --bare clone" so it
could imply "git clone --bare".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/