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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Matthieu Moy <hidden>
Date: 2016-06-15 23:07:16

Jacob Keller [off-list ref] writes:
On Wed, Nov 18, 2015 at 9:20 AM, Ronny Borchert [off-list ref] wrote:
quoted
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

From: Jeff King <hidden>
Date: 2016-06-15 23:07:17

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help