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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.