{"thread":{"id":"40830","subject":"[BUG] --bare is ignored before command word","startedAt":"2015-11-18T17:20:01Z","lastAt":"2015-11-20T14:52:48Z","messageCount":5,"participants":["Ronny Borchert","Jacob Keller","Matthieu Moy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273478","messageId":"loom.20151118T181639-5@post.gmane.org","threadId":"40830","inReplyTo":null,"subject":"[BUG] --bare is ignored before command word","fromName":"Ronny Borchert","fromEmail":"mister_rs@web.de","sentAt":"2015-11-18T17:20:01Z","receivedAt":"2015-11-18T17:20:01Z","isPatch":false,"sender":{"key":"mister_rs@web.de","avatar":null},"body":"I was trying to clone a bare repository. Not sure why I did, maybe\ndescription on website was wrong.\nMy try:\n\ngit --bare clone https://github.....\n\nThis was leading in creating a none bare repository! No error or warning\nmessage here!\nI guess this behavior is also for other --xxx commands.\n"},{"id":"273481","messageId":"CA+P7+xoD2-eDZQt29KBqZF2g4i+K7XhJG0mhUgqf5iDURBPntg@mail.gmail.com","threadId":"40830","inReplyTo":"loom.20151118T181639-5@post.gmane.org","subject":"Re: [BUG] --bare is ignored before command word","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-11-18T20:08:37Z","receivedAt":"2015-11-18T20:08:37Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Nov 18, 2015 at 9:20 AM, Ronny Borchert <mister_rs@web.de> wrote:\n> I was trying to clone a bare repository. Not sure why I did, maybe\n> description on website was wrong.\n> My try:\n>\n> git --bare clone https://github.....\n>\n> This was leading in creating a none bare repository! No error or warning\n> message here!\n> I guess this behavior is also for other --xxx commands.\n>\n\nThis is how the git options work. Options before a command word are\nalways ignored. It may be better to warn about these options though,\nso that they don't cause errors? The reasoning this is done is because\noptions between git and its command word are used to modify general\ngit behavior, while options after the command word modify each\nspecific command in their own way.\n\nRegards,\nJake\n"},{"id":"273484","messageId":"vpqa8qbov2n.fsf@anie.imag.fr","threadId":"40830","inReplyTo":"CA+P7+xoD2-eDZQt29KBqZF2g4i+K7XhJG0mhUgqf5iDURBPntg@mail.gmail.com","subject":"Re: [BUG] --bare is ignored before command word","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-11-18T21:29:20Z","receivedAt":"2015-11-18T21:29:20Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jacob Keller <jacob.keller@gmail.com> writes:\n\n> On Wed, Nov 18, 2015 at 9:20 AM, Ronny Borchert <mister_rs@web.de> wrote:\n>> I was trying to clone a bare repository. Not sure why I did, maybe\n>> description on website was wrong.\n>> My try:\n>>\n>> git --bare clone https://github.....\n>>\n>> This was leading in creating a none bare repository! No error or warning\n>> message here!\n>> I guess this behavior is also for other --xxx commands.\n>>\n>\n> This is how the git options work. Options before a command word are\n> always ignored.\n\nNo, they are not ignored. For example\n\n$ git --foobar init\nUnknown option: --foobar\n\n=> the option is processed, and rejected explicitly.\n\nBut as you say, options before the command word apply to \"git\", not to\nthe particular command. The case of --bare is a bit unfortunate: both\n\"git\" and \"git clone\" accept a --bare option, with a different meaning\n(read \"man git\" to find what the first does).\n\nSo, I wouldn't call the current behavior a really good one, but it's the\ndocumented behavior.\n\nIt would be nice to warn in this case though: I don't see any use for\n\"git --bare clone\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"273490","messageId":"20151119044646.GA8059@sigill.intra.peff.net","threadId":"40830","inReplyTo":"vpqa8qbov2n.fsf@anie.imag.fr","subject":"Re: [BUG] --bare is ignored before command word","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-19T04:46:46Z","receivedAt":"2015-11-19T04:46:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 18, 2015 at 10:29:20PM +0100, Matthieu Moy wrote:\n\n> But as you say, options before the command word apply to \"git\", not to\n> the particular command. The case of --bare is a bit unfortunate: both\n> \"git\" and \"git clone\" accept a --bare option, with a different meaning\n> (read \"man git\" to find what the first does).\n> \n> So, I wouldn't call the current behavior a really good one, but it's the\n> documented behavior.\n> \n> It would be nice to warn in this case though: I don't see any use for\n> \"git --bare clone\".\n\nWe have a similar situation for \"git init\". Once upon a time there was\njust \"git --bare init\", and then 74d3b23 (git-init: accept --bare\noption, 2008-05-28) let us do it either way.\n\nI'm tempted to say that \"git --bare clone\" should work the same way.\nBoth init and clone are special in that they are always about creating a\nnew repository, not working in an existing one.  That's technically a\nnon-compatible behavior change, but AFAICT with the current code the\noption is silently ignored, which just seems buggy.\n\nBut perhaps I am missing some useful effect it does have.\n\nI'd also be OK with simply flagging it as useless and issuing a warning\nor error.\n\n-Peff\n"},{"id":"273547","messageId":"vpqfv00hge7.fsf@anie.imag.fr","threadId":"40830","inReplyTo":"20151119044646.GA8059@sigill.intra.peff.net","subject":"Re: [BUG] --bare is ignored before command word","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-11-20T14:52:48Z","receivedAt":"2015-11-20T14:52:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Nov 18, 2015 at 10:29:20PM +0100, Matthieu Moy wrote:\n>\n>> But as you say, options before the command word apply to \"git\", not to\n>> the particular command. The case of --bare is a bit unfortunate: both\n>> \"git\" and \"git clone\" accept a --bare option, with a different meaning\n>> (read \"man git\" to find what the first does).\n>> \n>> So, I wouldn't call the current behavior a really good one, but it's the\n>> documented behavior.\n>> \n>> It would be nice to warn in this case though: I don't see any use for\n>> \"git --bare clone\".\n>\n> We have a similar situation for \"git init\". Once upon a time there was\n> just \"git --bare init\", and then 74d3b23 (git-init: accept --bare\n> option, 2008-05-28) let us do it either way.\n>\n> I'm tempted to say that \"git --bare clone\" should work the same way.\n> Both init and clone are special in that they are always about creating a\n> new repository, not working in an existing one.  That's technically a\n> non-compatible behavior change, but AFAICT with the current code the\n> option is silently ignored, which just seems buggy.\n\nI agree with this. I can't see a real use-case \"git --bare clone\" so it\ncould imply \"git clone --bare\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}