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: Thu, 22 Jul 2010 11:06:39 +0200 [thread overview]
Message-ID: <201007221106.39623.trast@student.ethz.ch> (raw)
In-Reply-To: <7v39venom7.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
[moved up this chunk from the end]
> If you instead choose to retain the "start from one commit", then the way
> you ask the question becomes "I have these lines in these files at this
> commit; explain how they came about in the history", which is exactly what
> you ask "blame". You are just using a different presentation from what
> the default "blame" output gives.
[...]
> > 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.
>
> I would consider it similar to "blame --incremental"; you can choose a
> very different output format driven by a single switch to change the mode
> of operation.
For me (and Bo seemed to agree off-list) the main interest is in the
*history*. Yes, it is an important feature that the diffs are also
limited to the ranges you are scanning, but that is the secondary
feature.
[If you think that is unfair, consider: if you remove the history
filtering or view, the line-log becomes log or blame, respectively.
If you just remove the diff display, it's still a new mode of history
simplification.]
In the rest of the mail I'll make some more points why it is more
log-like than blame-like, but this is the main point.
The comparison to "blame --incremental" is not valid because blame
always shows exactly one commit per line. That's not history in my
book. It does not even compute the history that line-log computes (it
gives up on tracking a line once it has assigned blame for it) so it
is not a new output format of existing data either.
> I think "log -L" conceptually is very different from the normal "log with
> pathspecs".
>
> The "log with pathspecs" is about "I have these histories that lead to
> these commits; show commits that touch paths that match them". On the
> other hand, "log -L" asks "I have these lines in these files; explain how
> they came about in the history leading to...". Now, the question is:
> "leading to" WHAT?
If pathspec limiting wasn't broken in the sense that it does not
support --follow (properly, anyway), they would be exactly equivalent.
With --follow, you would mean "I have these files, please explain how
they came about", and you would expect git to track renames and
copies.
That the current "I want to see some history, but only when it touched
this file" works is a fortunate side effect of the fact that people
rarely rename files (and that if they do, there are few collisions so
simply adding the old name usually works).
In particular, proper log --follow would have a problem exactly
analogous to:
> Because you start from "I have _these lines_", you are fundamentally
> discussing contents that appear as a set of line ranges _in a particular
> version_, adjusting the range to match their older incarnations as
> necessary as you dig deeper, no?
[...]
> E.g. if you have a history of this shape where commit C is at the tip:
>
> ---o---A---x---B---o---C
>
> you _could_ ask "log -p -L1,10,B:Makefile A..C" (I am not proposing this
> syntax at all, by the way) to browse the history between A and C, looking
> for commits that touch the region of Makefile that appeared as lines 1..10
> in revision B. Between B and C, some new lines might have been introduced
> inside the range and you would dig in reverse enlarging the range to show
> what have been added to it.
[I think this would be entirely possible to do for the line-log case,
though it would be too much effort for GSoC since it is also a
hard-to-explain and probably rarely-used case.]
Similarly, the plans for simplification that I have discussed with Bo
are roughly:
* commits that take all ranges from one of their parents are simplified
away (even if a merge)
* commits that take each range fully from a single parent should stay
but not show a diff
* ranges that are "split" between parents should show some format of
diff
Compare this to pathspec filtering:
* commits that are TREESAME to one of their parents are simplified
away
* commits that take each hunk literally from a single parent do not
show a diff with --cc
* commits that have hunks "mixed" from the parents show a diff
[The latter was first and served a guideline, of course.]
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2010-07-22 9:07 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
2010-07-20 15:45 ` Junio C Hamano
2010-07-22 9:06 ` Thomas Rast [this message]
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=201007221106.39623.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).