From: Thomas Rast <trast@student.ethz.ch>
To: git@vger.kernel.org
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
"Junio C Hamano" <gitster@pobox.com>,
"Santi Béjar" <santi@agolina.net>
Subject: [PATCH v2 0/2] bash completion: more options for gitk/log/shortlog
Date: Mon, 16 Feb 2009 17:34:55 +0100 [thread overview]
Message-ID: <cover.1234801852.git.trast@student.ethz.ch> (raw)
In-Reply-To: <adf1fd3d0902150156w67a16e6fp3c946446c5ae2bfd@mail.gmail.com>
Santi Béjar wrote:
> 2009/2/15 Junio C Hamano <gitster@pobox.com>:
> > Many options you add here are useful for git-log and not present in its
> > completion, but as you point out not all git-log options necessarily make
> > sense for gitk. I think it would make sense to introduce an extra
> > variable $__git_log_basic_options that holds the basic ones that can be in
> > both, and add the ones that are specific to gitk or git-log in their own
> > completion functions. I suspect gitk's addition will be nil, while
> > git-log would add --graph, --walk-reflogs and --no-merges to the basic
> > set.
Right. Somehow git patches have a tendency to grow in scope; while I
was trying to refactor them in good ways, I couldn't help notice that
shortlog falls in the same category.
(Probably there's another log-like command that I missed?)
> I sometimes use the --no-merges with gitk, normally within a range
> (the last 'next' update or so).
For me that falls in the "mangles history in horrible ways" category,
but since you use it, I put it in.
2/2 is new; I figured since gitk has this bit of code already, why not
have git-log do it the same way?
Thomas Rast (2):
bash completion: refactor common log, shortlog and gitk options
bash completion: only show 'log --merge' if merging
contrib/completion/git-completion.bash | 56 ++++++++++++++++++++++---------
1 files changed, 40 insertions(+), 16 deletions(-)
next prev parent reply other threads:[~2009-02-16 16:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-14 19:54 [PATCH] bash completion: offer more options for gitk Thomas Rast
2009-02-15 9:33 ` Junio C Hamano
2009-02-15 9:56 ` Santi Béjar
2009-02-16 16:34 ` Thomas Rast [this message]
2009-02-16 16:38 ` [PATCH v2 0/2] bash completion: more options for gitk/log/shortlog Thomas Rast
2009-02-16 19:00 ` [RFC PATCH] format-patch: thread as reply to cover letter even with in-reply-to Thomas Rast
2009-02-16 20:22 ` Jay Soffian
2009-02-16 20:34 ` Thomas Rast
2009-02-16 20:52 ` Jakub Narebski
2009-02-16 23:27 ` Thomas Rast
2009-02-19 21:26 ` [PATCH 0/4] format-patch --cover-letter --in-reply-to Thomas Rast
2009-02-19 21:26 ` [PATCH 1/4] format-patch: threading test reactivation Thomas Rast
2009-02-19 21:26 ` [PATCH 2/4] format-patch: track several references Thomas Rast
2009-02-19 22:41 ` Daniel Barkalow
2009-02-20 19:55 ` [PATCH v2 next 0/4] format-patch --cover-letter --in-reply-to Thomas Rast
2009-02-20 19:55 ` [PATCH v2 next 1/4] format-patch: threading test reactivation Thomas Rast
2009-02-20 19:55 ` [PATCH v2 next 2/4] format-patch: track several references Thomas Rast
2009-02-20 19:55 ` [PATCH v2 next 3/4] format-patch: thread as reply to cover letter even with in-reply-to Thomas Rast
2009-02-20 19:55 ` [PATCH v2 next 4/4] format-patch: support deep threading Thomas Rast
2009-02-22 16:49 ` [PATCH v2 next 0/4] format-patch --cover-letter --in-reply-to Junio C Hamano
2009-02-19 21:26 ` [PATCH 3/4] format-patch: thread as reply to cover letter even with in-reply-to Thomas Rast
2009-02-19 21:26 ` [PATCH 4/4] format-patch: support deep threading Thomas Rast
2009-02-16 16:34 ` [PATCH v2 1/2] bash completion: refactor common log, shortlog and gitk options Thomas Rast
2009-02-16 16:34 ` [PATCH v2 2/2] bash completion: only show 'log --merge' if merging Thomas Rast
2009-02-18 17:05 ` Shawn O. Pearce
2009-02-18 19:02 ` Junio C Hamano
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=cover.1234801852.git.trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=santi@agolina.net \
--cc=spearce@spearce.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;
as well as URLs for NNTP newsgroup(s).