All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.