From: Luben Tuikov <ltuikov@yahoo•com>
To: Jakub Narebski <jnareb@gmail•com>,
Rafael Garcia-Suarez <rgarciasuarez@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame
Date: Tue, 3 Jun 2008 13:35:31 -0700 (PDT) [thread overview]
Message-ID: <940824.46903.qm@web31808.mail.mud.yahoo.com> (raw)
In-Reply-To: <b77c1dce0806030600x520d35edxbe6e732ce6cc4ad6@mail.gmail.com>
--- On Tue, 6/3/08, Rafael Garcia-Suarez <rgarciasuarez@gmail•com> wrote:
> From: Rafael Garcia-Suarez <rgarciasuarez@gmail•com>
> Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame
> To: "Jakub Narebski" <jnareb@gmail•com>
> Cc: git@vger•kernel.org, "Luben Tuikov" <ltuikov@yahoo•com>
> Date: Tuesday, June 3, 2008, 6:00 AM
> 2008/6/3 Jakub Narebski <jnareb@gmail•com>:
> >>> I'd rather remove this, correct it, or
> make it optional (this is very
> >>> fork-heavy).
> >>
> >> Not sure how to do the same thing in pure Perl.
> >
> > I was thinking about extending git-blame porcelain
> format (and also
> > incremental format, of course) by 'parents'
> (and perhaps
> > 'original-parents') header...
>
> 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.
The intention was that it shouldn't necessarily be the (strict) parent
of the change (changed segment), since it may or may not have changed
in the strict parent commit. The intention was that it "starts"/"opens"
the parent commit so that "git" would start from there and find the actual
change/commit where that line/segment has changed. And it has worked
pretty fine for me when data-mining (something I do quite often) code
evolution.
My commit 244a70e608204a515c214a11c43f3ecf7642533a was really derived
from a command line, which I had started to use quite often and had
been "looking for" for quite some time.
> >> We could however cache the results of
> git-rev-parse, since the same
> >> rev is likely to appear many times in the list.
> >
> > ...but starting with cache of git-rev-parse results,
> or optionally
> > allowing extended sha-1 syntax (including
> <hash>^) in hash* CGI
> > parameters in gitweb would be a good idea.
> >
> > But as I wrote, I'm fine with the patch as it is
> now.
>
> I've sent a new version (take 2) with caching. And
> comments, as Lea suggested :)
Yes, hashing is good if it speeds up lookups without altering
intended functionality.
Thanks everyone!
Luben
next prev parent reply other threads:[~2008-06-03 20:36 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
2008-06-03 20:35 ` Luben Tuikov [this message]
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=940824.46903.qm@web31808.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 \
/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