From: Thomas Rast <trast@student.ethz.ch>
To: Junio C Hamano <gitster@pobox.com>
Cc: Bo Yang <struggleyb.nku@gmail.com>, <git@vger.kernel.org>
Subject: Re: [PATCH v3 05/13] parse the -L options
Date: Tue, 20 Jul 2010 09:51:55 +0200 [thread overview]
Message-ID: <201007200951.56218.trast@student.ethz.ch> (raw)
In-Reply-To: <7veiezni4m.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > I think that would just needlessly break the analogy to git-blame.[0]
> > With the current code,
> >
> > git blame -L 2,3 <path>
> > git log -L 2,3 <path>
> >
> > work the same.
>
> I like the general direction, but I am not sure how far we want to take
> that analogue with blame, though.
>
> For example, Bo's "log -L" thing also works on more than one path, no? I
> suspect it might be be reasonable to teach "blame" to annotate more than
> one path (with ranges) the same way. There is no technical limitation in
> the underlying scoreboard mechanism to prevent it from happening.
>
> Very similar to "blame" but quite differently from any normal "log"
> operation, "log -L" allows only one positive commit (starting point).
AFAICT this is not a conceptual requirement, only one of the current
implementation/option parsing. [Bo, how hard would it be to remove
this requirement?]
'git log --follow', if it were ever unbroken, would have much the same
problem that while technically allowing more than one starting point,
using that is only possible if the starting filename happens to agree
on all of them.
> Perhaps these argue that this new feature shouldn't be a new option of
> "log" at the UI level after all; rather, I wonder if this should be better
> presented as a new mode of "blame" (e.g. "blame --log", unlike showing
> "cvs annotate" like output, shows history like "git log" does).
Then you suddenly have a mode of git-blame that takes the normal
options, and another that takes all the git-log arguments that pertain
to commit formatting.
(Ok, you can't reasonably give it any of the diff-formatting options,
but e.g. --graph and --pretty are supposed to work.)
What's more, we (well, I do anyway) absolutely want gitk to display
the same output eventually. So that would also suddenly give you an
example where gitk isn't so equivalent to git-log-in-a-fancy-window
any more.
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2010-07-20 7:52 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-11 6:18 [PATCH v3 01/13] parse-options: stop when encounter a non-option Bo Yang
2010-07-11 6:18 ` [PATCH v3 02/13] parse-options: add two helper functions Bo Yang
2010-07-12 16:45 ` Junio C Hamano
2010-07-11 6:18 ` [PATCH v3 03/13] add the basic data structure for line level history Bo Yang
2010-07-12 14:16 ` Bo Yang
2010-07-12 16:50 ` Junio C Hamano
2010-07-18 14:35 ` Bo Yang
2010-07-11 6:18 ` [PATCH v3 04/13] refactor parse_loc Bo Yang
2010-07-12 18:32 ` Junio C Hamano
2010-07-11 6:18 ` [PATCH v3 05/13] parse the -L options Bo Yang
2010-07-13 23:03 ` Junio C Hamano
2010-07-18 14:49 ` Bo Yang
2010-07-19 18:44 ` Junio C Hamano
2010-07-19 22:48 ` Thomas Rast
2010-07-19 23:53 ` Junio C Hamano
2010-07-20 7:51 ` Thomas Rast [this message]
2010-07-20 15:45 ` Junio C Hamano
2010-07-22 9:06 ` Thomas Rast
2010-07-23 2:08 ` Junio C Hamano
2010-07-20 15:46 ` Bo Yang
2010-07-20 15:47 ` Bo Yang
2010-07-11 6:18 ` [PATCH v3 06/13] export three functions from diff.c Bo Yang
2010-07-11 6:18 ` [PATCH v3 07/13] add range clone functions Bo Yang
2010-07-12 21:52 ` Junio C Hamano
2010-07-11 6:18 ` [PATCH v3 08/13] map/take range to parent Bo Yang
2010-07-12 21:52 ` Junio C Hamano
2010-07-11 6:18 ` [PATCH v3 09/13] print the line log Bo Yang
2010-07-12 21:52 ` Junio C Hamano
2010-07-11 6:18 ` [PATCH v3 10/13] map/print ranges along traversing the history topologically Bo Yang
2010-07-12 21:52 ` Junio C Hamano
2010-07-11 6:18 ` [PATCH v3 11/13] add --always-print option Bo Yang
2010-07-13 20:35 ` Junio C Hamano
2010-07-11 6:19 ` [PATCH v3 12/13] add two test cases Bo Yang
2010-07-11 6:19 ` [PATCH v3 13/13] some document update Bo Yang
2010-07-11 8:27 ` Jakub Narebski
2010-07-12 14:12 ` Bo Yang
2010-07-12 18:45 ` Junio C Hamano
2010-07-18 14:37 ` Bo Yang
2010-07-12 16:45 ` [PATCH v3 01/13] parse-options: stop when encounter a non-option 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=201007200951.56218.trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=struggleyb.nku@gmail.com \
/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).