Git development
 help / color / mirror / Atom feed
From: Jonas Fonseca <fonseca@diku.dk>
To: git@vger.kernel.org
Subject: [TIG RFC] Cleaning up tig's option handling
Date: Thu, 7 Feb 2008 00:57:34 +0100	[thread overview]
Message-ID: <20080206235734.GA9969@diku.dk> (raw)

Hello,

In my own usage of tig, I increasingly use git-log options like -S and
--all and rarely use any of the "native" tig options or subcommands.
The only exception is the option for entering the status view, which I
have even configured a hotkey for in my editor (reducing most commit
preparations to a simple combination of pressing 't', 'u', '.' with the
help of tig's yet unreleased command aliases :). Anyway, the above usage
pattern leads to weird looking command lines when multiple "--"s are
needed, e.g.:

	$ tig -- --all ^release -- tig.c

I would like to ask tig users out there on how to best proceed with
cleaning up the option handling so that tig will act more like gitk.
Besides making command lines more visually appealing, out-sourcing the
option handling to git-rev-parse will also make it easier to add
refreshing of the main view (similar to F5 in gitk) in the future.

My plan is to obsolete most of the options over the course of the next
(few) release(s) keeping only the options for help and version
information. This should be fairly harmless I hope. Remaining is the
question of what to do with the subcommands and the option for the
status view. Having optional subcommands for tig has the problem that it
may ending up conflicting with local branch or file names causing
dreadful ambiguity. On the other hand, given git-log's and git-diff's
vast amount of options, it won't conflict with any and it might be more
natural to say `tig show <rev>` and `tig status` than `tig --show` and
`tig --status`.

Below is the list of subcommands and options:
---------------------------------------------
tig 0.9.1-19-gc509eed (Dec 13 2007)

Usage: tig [options]
   or: tig [options] [--] [git log options]
   or: tig [options] log  [git log options]
   or: tig [options] diff [git diff options]
   or: tig [options] show [git show options]
   or: tig [options] <    [git command output]

Options:
  -l                          Start up in log view
  -d                          Start up in diff view
  -S                          Start up in status view
  -n[I], --line-number[=I]    Show line numbers with given interval
  -b[N], --tab-size[=N]       Set number of spaces for tab expansion
  --                          Mark end of tig options
  -v, --version               Show version and exit
  -h, --help                  Show help message and exit

-- 
Jonas Fonseca

             reply	other threads:[~2008-02-06 23:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-06 23:57 Jonas Fonseca [this message]
2008-02-07  6:30 ` [TIG RFC] Cleaning up tig's option handling Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080206235734.GA9969@diku.dk \
    --to=fonseca@diku.dk \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox