Re: [PATCH 0/3] the return of the strbuf

From: Shawn O. Pearce <spearce@spearce.org>
Date: Sep 18, 2007, 03:57 UTC
Message-ID: <20070918035721.GL3099@spearce.org>
In-Reply-To: <20070917133522.GD18176@artemis.corp>

Pierre Habouzit <madcoder@debian.org> wrote:

Show 9 quoted lines

> On lun, sep 17, 2007 at 12:52:11 +0000, Pierre Habouzit wrote:
> >   While getting rid of ->eof in strbuf (as it was somehow tasteless). It
> > made me aware of the fact that fast-import.c was using a custom buffer
> > implementation (I think that was the fourth if not the fifth). So here
> > is the series that eradicates it.
> 
> Shawn: Johannes makes me remark that you are git-fast-import author,
> hence may want to be Cc-ed of that series, so here is a mail so that you
> don't miss the thread.

Thanks. The subject caught my attention. The patches look good and fast-import is usually maintained by me applying them and Junio pulling from my fast-import tree. I'm doing that now.

BTW, I haven't thanked you for doing this cleanup work.  It really
is appreciated.  The code is definately more readable in the end.
Thanks.

> The list: it's often hard to know who you should Cc on a given change,
> I use format.headers to force Junio and git@, but sometimes you want a
> different set of persons. I wonder if this could not be wired in the
> repository, as a .gitattribute extension ?

The Linux kernel folks were talking about this not too long ago and the discussion spilled onto the git list when someone CC'd it in the middle of the thread. If I recall correctly it ended off with this is probably something that a build script should be doing, not something Git should do natively, as the data is readily available from tools like git-log.

Indeed in this case if you do:

 $ git log --pretty=format:%an --since=6.months.ago -- fast-import.c \
      | sort | uniq -c | sort -nr
  14 Shawn O. Pearce
   3 Pierre Habouzit
   3 Junio C Hamano
   2 Simon Hausmann
   2 Alex Riesen
   1 Theodore Ts'o
   1 Sven Verdoolaege
   1 Sami Farin
   1 Nicolas Pitre
   1 Luiz Fernando N. Capitulino
   1 Dana L. How
 
So you'd probably want to CC me on stuff in that file.  On the other hand
looking at something else that's much more important to Git:

  $ git log --pretty=format:%an --since=6.months.ago -- builtin-pack-objects.c \
       | sort | uniq -c | sort -nr
  38 Nicolas Pitre
  12 Junio C Hamano
   4 Dana L. How
   3 Martin Koegler
   3 Linus Torvalds
   3 Brian Downing
   2 Theodore Ts'o
   2 Dana How
   1 Luiz Fernando N. Capitulino
   1 Geert Bosch
   1 Alex Riesen

I don't think anyone would argue that CC'ing Nico and Junio on all sizeable pack-objects changes would be prudent. Dana too actually as he has been active in here recently. Meanwhile I don't make the 6 month cut. ;-)

The other alternative that men with real computing horsepower at their disposal can ask is through git-blame:

  $ git blame -C -C -w --porcelain builtin-pack-objects.c | grep 'author ' \
       | sort | uniq -c | sort -nr
  52 author Nicolas Pitre
  39 author Junio C Hamano
  22 author Linus Torvalds
   6 author Shawn O. Pearce
   6 author Dana L. How
   3 author Martin Koegler
  ...

Again Nico scores very high (52 commits surviving in current `next`) but so does Junio and Linus. The output of git-blame may actually be a better indicator of who Junio likes to CC when changes are made in this module.

Doing something like this automatically based on the filepaths shown by `git diff --name-only $cmit^ $cmt` could be expensive in terms of CPU time, and might offer little gain for an old hand who knows where the maintainer boundaries tend to be, but it does really help someone who is newer to the project and might not know who is the best person to talk to.

-- 
Shawn.