* [bug] Git submodule command interprets switch as argument and switch @ 2017-08-18 5:16 R0b0t1 2017-08-18 19:33 ` Stefan Beller 2017-08-18 20:38 ` Jonathan Nieder 0 siblings, 2 replies; 4+ messages in thread From: R0b0t1 @ 2017-08-18 5:16 UTC (permalink / raw) To: git The issue is as follows: R0b0t1@host:~/devel/project$ git submodule add https://github.com/user/project -f Cloning into '/home/R0b0t1/devel/project/-f'... My .gitignore's first line is *, and then I explicitly allow things. Despite the presence of "project/" in the .gitignore the submodule command says it is ignored. The "force" flag is interpreted as a flag and also as the destination directory. It is possible the argument parsing code for other commands exhibits this error. R0b0t1. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bug] Git submodule command interprets switch as argument and switch 2017-08-18 5:16 [bug] Git submodule command interprets switch as argument and switch R0b0t1 @ 2017-08-18 19:33 ` Stefan Beller 2017-08-18 20:38 ` Jonathan Nieder 1 sibling, 0 replies; 4+ messages in thread From: Stefan Beller @ 2017-08-18 19:33 UTC (permalink / raw) To: R0b0t1, Prathamesh Chavan; +Cc: git@vger.kernel.org On Thu, Aug 17, 2017 at 10:16 PM, R0b0t1 <r030t1@gmail.com> wrote: > The issue is as follows: > > R0b0t1@host:~/devel/project$ git submodule add > https://github.com/user/project -f > Cloning into '/home/R0b0t1/devel/project/-f'... > > My .gitignore's first line is *, and then I explicitly allow things. > Despite the presence of "project/" in the .gitignore the submodule > command says it is ignored. That might indicate that another submodule command doesn't cope with submodule names that look like a common flag. > The "force" flag is interpreted as a flag > and also as the destination directory. > > It is possible the argument parsing code for other commands exhibits this error. Yes, though these other commands are in C, not in shell. Note that Prathamesh is currently porting the "git submodule" command to C, which would allow us to fix this bug easily. Also note that the -f is ambigious, what if the user meant to have the submodule at path "-f" ? (This issue comes up in many other commands, for example when a path and a branch name is accepted, the path of a potentially deleted file. To solve this git accepts a double dash, which signals git that anything after the double dash there are arguments not to be interpreted as a command line flag. > > R0b0t1. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bug] Git submodule command interprets switch as argument and switch 2017-08-18 5:16 [bug] Git submodule command interprets switch as argument and switch R0b0t1 2017-08-18 19:33 ` Stefan Beller @ 2017-08-18 20:38 ` Jonathan Nieder 2017-08-18 21:35 ` R0b0t1 1 sibling, 1 reply; 4+ messages in thread From: Jonathan Nieder @ 2017-08-18 20:38 UTC (permalink / raw) To: R0b0t1; +Cc: git, Stefan Beller Hi, R0b0t1 wrote: > The issue is as follows: > > R0b0t1@host:~/devel/project$ git submodule add > https://github.com/user/project -f > Cloning into '/home/R0b0t1/devel/project/-f'... Thanks for reporting. Confusingly, I think this is intended behavior. "git help submodule" explains: add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>] Add the given repository as a submodule at the given path [etc] Since the -f comes after <repository>, it is a <path>. That said, there are a few related things wrong here. The usage string above says I can put "--" before the <repository> to make things extra unambiguous. But when I try that, I get the following result: $ git submodule add -- https://gerrit.googlesource.com/gerrit -f Cloning into '/tmp/t/test/-f'... [...] Resolving deltas: 100% (215796/215796), done. /usr/lib/git-core/git-submodule: line 261: cd: -f: invalid option cd: usage: cd [-L|[-P [-e]] [-@]] [dir] Unable to checkout submodule '-f' If I try to put the "--" between <repository> and <path>, I get another confusing result: $ git submodule add https://gerrit.googlesource.com/gerrit -- -f '--' already exists in the index "git help cli" is supposed to give advice about this kind of thing as well --- e.g., it gives some sound advice about what form of flags scripts should use (e.g., to always use the 'stuck' form --name=<name> instead of --name name). But it doesn't mention this issue of flags belonging before other arguments. Thoughts? Thanks, Jonathan ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bug] Git submodule command interprets switch as argument and switch 2017-08-18 20:38 ` Jonathan Nieder @ 2017-08-18 21:35 ` R0b0t1 0 siblings, 0 replies; 4+ messages in thread From: R0b0t1 @ 2017-08-18 21:35 UTC (permalink / raw) To: Jonathan Nieder; +Cc: git, Stefan Beller On Fri, Aug 18, 2017 at 3:38 PM, Jonathan Nieder <jrnieder@gmail.com> wrote: > Hi, > > R0b0t1 wrote: > >> The issue is as follows: >> >> R0b0t1@host:~/devel/project$ git submodule add >> https://github.com/user/project -f >> Cloning into '/home/R0b0t1/devel/project/-f'... > > Thanks for reporting. Confusingly, I think this is intended behavior. > "git help submodule" explains: > > add [-b <branch>] [-f|--force] [--name <name>] > [--reference <repository>] [--depth <depth>] [--] > <repository> [<path>] > > Add the given repository as a submodule at the given > path [etc] > > Since the -f comes after <repository>, it is a <path>. > Not to comment on every response to this bug, but I understand. What is confusing is that the command was failing without being forced, and without thinking I added "-f" at the end. The command succeeded as if I supplied the force flag, but per my experience with other tools, and with other Git commands, "-f" should not be a flag. It should be a path, as you say. However it appears to be both. To reproduce my situation exactly, add "*" to your .gitignore. The directory "gerrit" should then be ignored, and Git will warn you that the submodule will not be tracked (I may have another issue to report related to this, but I'm still trying to figure out what is going on). However, if you name the directory something else, like "-f", it will still be matched by the .gitignore rule and should not succeed. This is why I think the path is also being interpreted as a flag. Something else may be happening, but either way the behavior does not seem to be expected nor consistent with other parts of Git. > That said, there are a few related things wrong here. > > The usage string above says I can put "--" before the <repository> to > make things extra unambiguous. But when I try that, I get the following > result: > > $ git submodule add -- https://gerrit.googlesource.com/gerrit -f > Cloning into '/tmp/t/test/-f'... > [...] > Resolving deltas: 100% (215796/215796), done. > /usr/lib/git-core/git-submodule: line 261: cd: -f: invalid option > cd: usage: cd [-L|[-P [-e]] [-@]] [dir] > Unable to checkout submodule '-f' > > If I try to put the "--" between <repository> and <path>, I get another > confusing result: > > $ git submodule add https://gerrit.googlesource.com/gerrit -- -f > '--' already exists in the index > > "git help cli" is supposed to give advice about this kind of thing as > well --- e.g., it gives some sound advice about what form of flags > scripts should use (e.g., to always use the 'stuck' form --name=<name> > instead of --name name). But it doesn't mention this issue of flags > belonging before other arguments. > > Thoughts? > I have experienced issues with -- before. It has been long enough I have forgotten. Sorry for not being able to provide anything concrete. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-18 21:35 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-18 5:16 [bug] Git submodule command interprets switch as argument and switch R0b0t1 2017-08-18 19:33 ` Stefan Beller 2017-08-18 20:38 ` Jonathan Nieder 2017-08-18 21:35 ` R0b0t1
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).