Sidhant Sharma [off-list ref] writes:
On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote:
quoted
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).
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.
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!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Monday 21 March 2016 01:59 PM, Matthieu Moy wrote:
Sidhant Sharma [off-list ref] writes:
quoted
On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote:
quoted
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.
quoted
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 :)