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:03:52 -0700 (PDT) [thread overview]
Message-ID: <354228.30165.qm@web31807.mail.mud.yahoo.com> (raw)
In-Reply-To: <200806031614.29161.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:14 AM
> On Tue, 3 June 2008, Rafael Garcia-Suarez wrote:
> > 2008/6/3 Jakub Narebski <jnareb@gmail•com>:
> >>>
> >>> OK, I see. That would be nice. Also: currently
> taking "$full_rev^"
> >>> directs the user to the parent commit, but it
> would be more
> >>> user-friendly to point at the previous commit
> where the selected file
> >>> was modified instead.
> >>
> >> That's what I meant by distinguishing between
> 'parents' and
> >> 'original-parents' (or
> 'rewritten-parents' and 'parents'): first
> are
> >> rewritten parents in history limited to specified
> file (with the
> >> addition of code movements and copying across
> files/filenames),
> >> second are original parents of a commit.
> >>
> >> For gitweb we would use the first set (I wonder
> what to do in the case
> >> of merge commit, i.e. more than one parent).
> >
> > Currently that takes the left parent. Or something.
> >
> > 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?
>
> I'd like to say that I prefer gitweb's marking
> blame by blocks, not by
> lines, and extra info on mouseover.
Completely agree.
> But having blame
> navigation
> capability of perforce web interface would be really nice
> (I think
> "git gui blame" has something like this; I
> don't know about other
> tools like qgit, giggle, or ugit).
That was the intention of git_blame2()... myself just previously coming
from perforce...
So yes, long time ago, in a galaxy far, far away, I was using perforce for
data mining of the evolution of the code, in order to deduct intention.
And I had wanted the same capability in git, thus git_blame2 and commit
244a70e608204a515c214a11c43f3ecf7642533a.
> BTW. how in your opinion Git compares to Perforce, both as
> a tool
> itself, and also about quality of companion tools such like
> gitweb
> or git-gui?
What I did was prompted by what I had used with perforce, and on top
of it, improving on it.
So yes, I like git and gitweb. At the moment they give me what I need,
and of course an edge over other SCMs is the distributed nature of git.
Thanks!
Luben
>
> > I'm more or
> less trying to
> > duplicate this blame log navigation in gitweb. So it
> might result in a
> > few patches here :)
>
> I think it would be really nice. 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?
>
> --
> Jakub Narebski
> Poland
next prev parent reply other threads:[~2008-06-03 21:04 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
2008-06-03 21:03 ` Luben Tuikov [this message]
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=354228.30165.qm@web31807.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