git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Rafael Garcia-Suarez" <rgarciasuarez@gmail.com>
Cc: git@vger.kernel.org, "Luben Tuikov" <ltuikov@yahoo.com>,
	"Sam Vilain" <sam@vilain.net>
Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame
Date: Tue, 3 Jun 2008 16:14:28 +0200	[thread overview]
Message-ID: <200806031614.29161.jnareb@gmail.com> (raw)
In-Reply-To: <b77c1dce0806030636i434e4716r8a52d6aeb93e9719@mail.gmail.com>

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

> Since we're going to move the official perl 5 vcs to git (many many
> thanks to Sam Vilain for that, BTW),

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?

>                                       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

  reply	other threads:[~2008-06-03 14:15 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 [this message]
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
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=200806031614.29161.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ltuikov@yahoo.com \
    --cc=rgarciasuarez@gmail.com \
    --cc=sam@vilain.net \
    /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).