On Monday 21 March 2016 01:59 PM, Matthieu Moy wrote:
> Sidhant Sharma <tigerkid...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
