On Monday 21 March 2016 01:59 PM, Matthieu Moy wrote: > Sidhant Sharma <tigerkid001@xxxxxxxxx> writes: > >> On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote: >> >>> Note that it implies writting an almost full-blown option parser to >>> recognize commands like >>> >>> ggit --work-tree git --namespace reset --git-dir --hard git log >>> >>> (just looking for "git", "reset" and "--hard" in the command-line would >>> not work here). >> Could you please elaborate on the above command, I'm unable to >> understand its syntax. I thought all git commands follow the >> `git command <arguments>` syntax, so using simple string >> manipulations and regexes would work. Am I missing something? > The full syntax is > > git [global options] <command> [options and arguments for a command] > > For example: > > git -p log => -p is the option for "git" itself, which means "paginate" > git log -p => -p is the option for "git log", which means "patch" > > Options can have stuck or non-stuck form, for example > > git --work-tree=foo <=> git --work-tree foo > > git --work-tree git --namespace reset --git-dir --hard git log > <=> > git --work-tree=git --namespace=reset --git-dir=--hard git log > > (This is probably a stupid command to type, but it's legal) > > The later is source of issues for a parser since you can't just iterate > through argv[] and search for problematic commands/options, since you > have to distinguish options themselves (--work-tree above) and option > arguments (foo above). Thanks for the explanation; I knew of the global options but didn't know that the last command would be syntactically legal. For commands like such iterating over argv[] wouldn't work (not in all cases). Though a beginner may not enter commands of this sort, I agree we shouldn't rely on that. If it were only for stuck commands, regexes would've worked. I can now see why a parser would be needed here, which can recognize global options and the above command syntax. But for this example, > In my example above, I played with global options (before "git" in the > command-line), but I could also have done that with per-command options > taking arguments, like > > git push --repo --force > > Here, --force is the name of the repo (again, probably a stupid name, > but why not), not the --force option. would the parser also be required to understand all options and arguments for all git commands? Although --force could not be a branch name (git denies it), but it may not be so for other commands. >> I wasn't sure if we are allowed to code before the actual coding period begins >> so I kept it that way. I'll update it now. > You're not "forced" to, but you can write code whenever you like. We've > already seen code written before the application! > Nice! I too would like to get started early :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html