Re: [PATCH] Add git-annotate, a tool for assigning blame.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, 23 Feb 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> >> > 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.
> >
> > The major problem is probably not solved: What Linus calls a "stream 
> > interface".
> >
> > I.e. if you pipe the output of git-rev-list to another program, you 
> > *need* to execute the two semi-simultaneously. The "alternative" would be 
> > to use buffers, which can get huge (and are sometimes not needed: think 
> > git-whatchanged, which starts outputting before it's getting no more 
> > input).
> 
> You need a limited coroutine support, something like generator
> functions in Python ;-).  In C, traditional way of doing it is
> to make your application specific function a callback of
> rev-list or whatever generator is, which is very unpleasant to
> code.

The most unpleasant aspect is that you usually need something like "this" 
in C++: a pointer to an object (which you have to pass around all the 
time). Without it you can not use the function in a nested way.

However, I can also see benefits of this when compared to the traditional 
UNIX approach. It should be faster, for one, since you don't need to pass 
data through pipes all the time. (This might be not as true for Linux as 
for other OSes.)

Ciao,
Dscho

-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]