Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jun 3, 2008, 21:03 UTC
Message-ID: <354228.30165.qm@web31807.mail.mud.yahoo.com>
In-Reply-To: <200806031614.29161.jnareb@gmail.com>

--- On Tue, 6/3/08, Jakub Narebski <jnareb@gmail.com> wrote:

Show 50 quoted lines

> 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.

Show 7 quoted lines

>  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.

Show 5 quoted lines

> 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

Show 17 quoted lines

> 
> >                                       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