Hi, Christian Couder writes: > On Saturday 09 July 2011 17:41:57 Ramkumar Ramachandra wrote: >> I've decided not to support arbitrary command-line options in the >> instruction sheet. > > It may be a good decision, but could you explain why? You could say for > example that the series would be already an improvement over what we have if > we don't parse arbitrary command line options. Here's an elaborate justification: 1. Parsing arbitrary command-line options means that we'd have to support two versions of every command: the short version and the long version. As a result, two configuration files may be functionally identical, but not really identical because one uses short versions and the other uses long versions. This is ugly/ inelegant. 2. The format can be quite loose: for example "--ff -s" is equivalent to "---ff '-s'". We'll either have to go through the trouble to sanitize everything at the time of persistence, or go through that trouble while reading. We can't entirely avoid this ugliness. 3. Where do we stop? Is something like "for i in "moo foo"; do $i; done;" allowed? How do we draw clear boundaries? 4. Most importantly, we're NOT building a fast git shell. There's no point implementing a reduced shell parser inside Git -- there are many existing shells we can leverage, if that's what we want. Besides, I can't think of a good enough usecase for per-instruction command-line options right now. How often would someone want to cherry-pick 10 commits, but signoff on 3 of them somewhere in the middle? Not to say that we should not support per-instruction command-line options: just that we can wait until someone figures out a great usecase + a good implementation. It's not critical. Let's go back to the problem at hand -- what are we trying to do? The problem is to get cherry-pick/ revert to support '--continue', and '--reset' as soon as possible and get it merged. So, all we need is one set of options to persist along with the head and todo. A simple "key = value" format is both simple and elegant; so we can go ahead with it, and see how things play out later. Since none of this is exposed to the end-user, I don't see us locking ourselves into short-sighted design at any rate. >> A typical instruction sheet will looks like this >> (inspired heavily by the rebase -i instruction sheet format): > >> pick 3b36854 t: add tests for cloning remotes with detached HEAD >> pick 61adfd3 consider only branches in guess_remote_head >> pick 8537f0e submodule add: test failure when url is not configured in >> superproject pick 4d68932 submodule add: allow relative repository path >> even when no url is set pick f22a17e submodule add: clean up duplicated >> code >> pick 59a5775 make copy_ref globally available >> pick c1921c1 clone: always fetch remote HEAD > > Would it be easy to change the format to support arbitrary command line > options if we want to do it afterwards, especially after the end of the GSoC? Why not? We aren't explicitly showing this to the end-user yet, so I see no problem with changing it. We should worry about that only when we develop a feature like "cherry-pick -i". >> For persisting one set of options for every "git cherry-pick"/ "git >> revert" invocation, I've decided to use a simple "key = value" format >> and put it in .git/sequencer/opts (to sit beside .git/sequencer/head >> and .git/sequencer/todo). For strategy-option, I thought it would be >> cute to separate the various options using ' | '. So, it'll look >> something like this in the end: >> >> signoff = true >> mainline = 1 >> strategy-option = recursive | ours > > Is it the same format as the .git/config file format? Would it be possible to > reuse some config parsing/writing code? Yes; I'm currently working on it. I just wanted to show a simple PoC, but I will try to avoid introducing new parsers and the bugs that come along with it. Thanks. -- Ram -- 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