{"thread":{"id":"11927","subject":"[TIG RFC] Cleaning up tig's option handling","startedAt":"2008-02-06T23:57:34Z","lastAt":"2008-02-07T06:30:48Z","messageCount":2,"participants":["Jonas Fonseca","Greg KH"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"67736","messageId":"20080206235734.GA9969@diku.dk","threadId":"11927","inReplyTo":null,"subject":"[TIG RFC] Cleaning up tig's option handling","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2008-02-06T23:57:34Z","receivedAt":"2008-02-06T23:57:34Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Hello,\n\nIn my own usage of tig, I increasingly use git-log options like -S and\n--all and rarely use any of the \"native\" tig options or subcommands.\nThe only exception is the option for entering the status view, which I\nhave even configured a hotkey for in my editor (reducing most commit\npreparations to a simple combination of pressing 't', 'u', '.' with the\nhelp of tig's yet unreleased command aliases :). Anyway, the above usage\npattern leads to weird looking command lines when multiple \"--\"s are\nneeded, e.g.:\n\n\t$ tig -- --all ^release -- tig.c\n\nI would like to ask tig users out there on how to best proceed with\ncleaning up the option handling so that tig will act more like gitk.\nBesides making command lines more visually appealing, out-sourcing the\noption handling to git-rev-parse will also make it easier to add\nrefreshing of the main view (similar to F5 in gitk) in the future.\n\nMy plan is to obsolete most of the options over the course of the next\n(few) release(s) keeping only the options for help and version\ninformation. This should be fairly harmless I hope. Remaining is the\nquestion of what to do with the subcommands and the option for the\nstatus view. Having optional subcommands for tig has the problem that it\nmay ending up conflicting with local branch or file names causing\ndreadful ambiguity. On the other hand, given git-log's and git-diff's\nvast amount of options, it won't conflict with any and it might be more\nnatural to say `tig show <rev>` and `tig status` than `tig --show` and\n`tig --status`.\n\nBelow is the list of subcommands and options:\n---------------------------------------------\ntig 0.9.1-19-gc509eed (Dec 13 2007)\n\nUsage: tig [options]\n   or: tig [options] [--] [git log options]\n   or: tig [options] log  [git log options]\n   or: tig [options] diff [git diff options]\n   or: tig [options] show [git show options]\n   or: tig [options] <    [git command output]\n\nOptions:\n  -l                          Start up in log view\n  -d                          Start up in diff view\n  -S                          Start up in status view\n  -n[I], --line-number[=I]    Show line numbers with given interval\n  -b[N], --tab-size[=N]       Set number of spaces for tab expansion\n  --                          Mark end of tig options\n  -v, --version               Show version and exit\n  -h, --help                  Show help message and exit\n\n-- \nJonas Fonseca\n"},{"id":"67754","messageId":"20080207063048.GA22148@kroah.com","threadId":"11927","inReplyTo":"20080206235734.GA9969@diku.dk","subject":"Re: [TIG RFC] Cleaning up tig's option handling","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2008-02-07T06:30:48Z","receivedAt":"2008-02-07T06:30:48Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Thu, Feb 07, 2008 at 12:57:34AM +0100, Jonas Fonseca wrote:\n> Hello,\n> \n> In my own usage of tig, I increasingly use git-log options like -S and\n> --all and rarely use any of the \"native\" tig options or subcommands.\n\nSame for my usage, and I use tig a lot too.\n\n> I would like to ask tig users out there on how to best proceed with\n> cleaning up the option handling so that tig will act more like gitk.\n\nAnything that works more like gitk would be fine with me, no objection\nto changing the options at all.\n\nthanks,\n\ngreg k-h\n"}]}