git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fredrik Kuivinen <freku045@student.liu.se>
To: Ryan Anderson <ryan@michonline.com>
Cc: Fredrik Kuivinen <freku045@student.liu.se>,
	Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] Add git-annotate, a tool for assigning blame.
Date: Thu, 23 Feb 2006 23:55:47 +0100	[thread overview]
Message-ID: <20060223225547.GB8673@c165.ib.student.liu.se> (raw)
In-Reply-To: <20060223221048.GA6423@mythryan2.michonline.com>

On Thu, Feb 23, 2006 at 05:10:49PM -0500, Ryan Anderson wrote:
> (Biased critique since I have the other tool in the tree, but still...)
> 
> > +    FILE* fout = fopen("/tmp/git-blame-tmp1", "w");
> 
> Probably should be using something like mkstemp (mkstmp?) here, so if
> someone is runnign things as root or with a malicous user around, things
> don't collide.
> 
> Hell, so on a multi-user machine this doesn't blow up on you.

Yep, I know. The code is mostly a proof of concept. I didn't submit it
for inclusion.


> 
> But, read down for a related comment.
> 
> > +    if(!fout)
> > +        die("fopen tmp1 failed: %s", strerror(errno));
> > +
> > +    if(fwrite(info_c->buf, info_c->size, 1, fout) != 1)
> > +        die("fwrite 1 failed: %s", strerror(errno));
> > +    fclose(fout);
> > +
> > +    fout = fopen("/tmp/git-blame-tmp2", "w");
> > +    if(!fout)
> > +        die("fopen tmp2 failed: %s", strerror(errno));
> > +
> > +    if(fwrite(info_o->buf, info_o->size, 1, fout) != 1)
> > +        die("fwrite 2 failed: %s", strerror(errno));
> > +    fclose(fout);
> > +
> > +    FILE* fin = popen("diff -u0 /tmp/git-blame-tmp1 /tmp/git-blame-tmp2", "r");
> > +    if(!fin)
> > +        die("popen failed: %s", strerror(errno));
> 
> Can't git-diff-tree do this sufficiently, anyway?  See my Perl script
> for an example, you just need both commit IDs and both filenames and the
> appropriate -M and you get the right results.
> 
> (It's possible that's part of where the performance differences are,
> though, not really sure at the moment.)
> 

Yeah.. maybe. My first thought was to avoid forking and execing diff
and use some C library for doing the diffing instead (libxdiff). But
then I just wanted to get some code working and the simplest solution
I could think of was to fork and exec diff.

> I'm going to stop there for the moment, I'm not really confident in my
> understanding of git-internals to say much more just yet.
> 
> This could probably benefit a *LOT* from the libification project, I
> think, though.

Yes, perhaps. Some of the git-rev-list bits might simplify a couple of
things.

I have found some severe problems with the code I posted, in
particular it doesn't handle parallel development tracks at all. I am
working on fixing it, but it isn't finished yet.

Thanks for the comments.

- Fredrik

  reply	other threads:[~2006-02-23 22:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-20 10:46 [PATCH] Add git-annotate, a tool for assigning blame Ryan Anderson
2006-02-20 22:54 ` Junio C Hamano
2006-02-20 23:40 ` Fredrik Kuivinen
2006-02-21  0:01   ` Junio C Hamano
2006-02-28  8:27     ` Fredrik Kuivinen
2006-02-28  8:38       ` Junio C Hamano
2006-02-28  8:47       ` Ryan Anderson
2006-02-28  9:08         ` Andreas Ericsson
2006-02-23 22:10   ` Ryan Anderson
2006-02-23 22:55     ` Fredrik Kuivinen [this message]
2006-02-24  0:00       ` Johannes Schindelin
2006-02-24  0:17         ` Junio C Hamano
2006-02-24  0:52           ` Johannes Schindelin
  -- strict thread matches above, loose matches on Subject: below --
2006-03-02  5:16 [PATCH 0/3] Annotate updates Ryan Anderson
2006-03-02  5:16 ` [PATCH] Add git-annotate, a tool for assigning blame Ryan Anderson
2006-03-02  5:20   ` Ryan Anderson

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=20060223225547.GB8673@c165.ib.student.liu.se \
    --to=freku045@student.liu.se \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=ryan@michonline.com \
    /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).