From: Luben Tuikov <ltuikov@yahoo•com>
To: Rafael Garcia-Suarez <rgarciasuarez@gmail•com>,
Jakub Narebski <jnareb@gmail•com>
Cc: git@vger•kernel.org, Sam Vilain <sam@vilain•net>
Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame
Date: Tue, 3 Jun 2008 14:09:53 -0700 (PDT) [thread overview]
Message-ID: <655725.88869.qm@web31813.mail.mud.yahoo.com> (raw)
In-Reply-To: <200806031656.04780.jnareb@gmail.com>
--- On Tue, 6/3/08, Jakub Narebski <jnareb@gmail•com> wrote:
> From: Jakub Narebski <jnareb@gmail•com>
> Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame
> To: "Rafael Garcia-Suarez" <rgarciasuarez@gmail•com>
> Cc: git@vger•kernel.org, "Luben Tuikov" <ltuikov@yahoo•com>, "Sam Vilain" <sam@vilain•net>
> Date: Tuesday, June 3, 2008, 7:56 AM
> Rafael Garcia-Suarez wrote:
> > 2008/6/3 Jakub Narebski <jnareb@gmail•com>:
> >>> Shameless plug : the sources for perl 5 are
> currently being kept in a
> >>> perforce repository. There is a rough web
> interface to it at
> >>>
> http://public.activestate.com/cgi-bin/perlbrowse with
> excellent blame
> >>> log navigation features (including navigation
> against p4
> >>> integrations).
> >>
> >> By the way, what is the difference between
> '<<' links and 'br' link
> >> in the above mentioned annotate/blame interface?
> >
> > "br" navigates to another branch from which
> this file has been
> > integrated (in p4 speak.)
>
> Does it mark merge commits then? Or perhaps branch points?
> What
> does "branch from which this file has been
> integrated" mean in git
> speak (in the terms of DAG of commits)?
>
>
> If the history of a file looks like this
>
> ....*---*---A---M---C...
> /
> ....*---B-/
>
> and the line comes from "evil merge" M git-blame
> would return M as
> blamed commit. If the line comes from one or the other
> branch, from
> commit A or B, it makes I think no difference to git-blame;
> git tries
> to be "branch agnostic" (no special meaning to
> first parent; well,
> besides rev~n notation and --first-parent walk option). I
> guess it
> is not the case in Perforce?
The whole point of git_blame2() was to show which "previous" commit
changed that line/segment and what the commit message was. This is
important to me when data-mining code evolution, since often enough
I'd like to recollect mine/other's intentions at the time of
changing/adding the code/commit in question.
>
> [...]
> >> [...]. Will you want to use git-diff-tree
> >> to mark differences from the version we came from
> (marked by 'hp',
> >> 'hpb' and 'fp' URI parameters), or
> would you rather extend git-blame?
> >
> > I don't know. I'll look at git-diff-tree.
>
> What I meant here, would you plan on extending git-blame,
> or would you
> use patchset (textual) diff between revision we are at, and
> revision we
> came from. git-diff-tree just compares two trees (and have
> to have
> patch output explicitely enabled). Sorry for the
> confusion.
I'd rather stray away from "git-diff-xyz", since there is no context.
Context is found in the commit message which changed the line/segment.
(By "context" I mean the human intention, most likely encoded in the
commit message.)
Thanks everyone!
Luben
next prev parent reply other threads:[~2008-06-03 21:10 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-03 10:46 [PATCH] Avoid errors from git-rev-parse in gitweb blame Rafael Garcia-Suarez
2008-06-03 11:42 ` Lea Wiemann
2008-06-03 11:43 ` Jakub Narebski
2008-06-03 12:03 ` Rafael Garcia-Suarez
2008-06-03 12:45 ` Jakub Narebski
2008-06-03 13:00 ` Rafael Garcia-Suarez
2008-06-03 13:12 ` Jakub Narebski
2008-06-03 13:36 ` Rafael Garcia-Suarez
2008-06-03 14:14 ` Jakub Narebski
2008-06-03 14:40 ` Rafael Garcia-Suarez
2008-06-03 14:56 ` Jakub Narebski
2008-06-03 15:07 ` Rafael Garcia-Suarez
2008-06-03 17:50 ` Jakub Narebski
2008-06-03 21:09 ` Luben Tuikov [this message]
2008-06-03 21:03 ` Luben Tuikov
2008-06-03 20:35 ` Luben Tuikov
2008-06-03 21:31 ` Jakub Narebski
2008-06-04 5:58 ` Junio C Hamano
2008-06-04 14:03 ` Jakub Narebski
2008-06-05 6:07 ` Junio C Hamano
2008-06-05 6:09 ` [PATCH 1/2] git-blame: refactor code to emit "porcelain format" output Junio C Hamano
2008-06-06 9:22 ` Jakub Narebski
2008-06-05 6:09 ` [PATCH 2/2] blame: show "previous" information in --porcelain/--incremental format Junio C Hamano
2008-06-06 9:27 ` Jakub Narebski
2008-06-06 15:17 ` Junio C Hamano
2008-06-06 15:44 ` Jakub Narebski
2008-06-06 0:26 ` [PATCH] Avoid errors from git-rev-parse in gitweb blame Jakub Narebski
2008-06-04 22:24 ` Luben Tuikov
2008-06-03 14:24 ` Lea Wiemann
2008-06-03 20:24 ` Jakub Narebski
2008-06-03 23:11 ` Lea Wiemann
2008-06-04 0:11 ` Jakub Narebski
2008-06-04 0:39 ` Lea Wiemann
2008-06-04 12:31 ` Jakub Narebski
2008-06-08 18:19 ` Lea Wiemann
2008-06-08 20:28 ` Jakub Narebski
2008-06-03 20:18 ` Luben Tuikov
2008-06-03 20:29 ` Jakub Narebski
2008-06-03 21:27 ` Luben Tuikov
2008-06-03 21:34 ` Jakub Narebski
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=655725.88869.qm@web31813.mail.mud.yahoo.com \
--to=ltuikov@yahoo$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
--cc=rgarciasuarez@gmail$(echo .)com \
--cc=sam@vilain$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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