linux-kernel - Re: git-send-email

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Feb 2009 11:39:24 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Ingo Oeser <ioe-lkml@...eria.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Junio C Hamano <gitster@...ox.com>,
	L-K <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: git-send-email

On Fri, Feb 13, 2009 at 10:34:05AM +0100, Ingo Oeser wrote:
> On Thursday 12 February 2009, Peter Zijlstra wrote:
> > > foobar patch 0 (usually a summary/overview)
> > > +-foobar patch 1
> > > +-foobar patch 2
> > > +-foobar patch 3
> > > +-foobar patch 4
> > > +-foobar patch 5
> > > 
> > > is much nicer than
> > > 
> > > foobar patch 0
> > > +-foobar patch 1
> > >   +-foobar patch 2
> > >     +-foobar patch 3
> > >       +-foobar patch 4
> > >         +-foobar patch 5
> > > 
> > > which seems to be what git does itself.
> > 
> > Which happens to be exactly what my suggestion would accomplish.
> 
> Ok, then I take back my reservations and support this idea.
> 
> Lennart: Thanks for visualizing what Peter meant :-)

Just in case anyone cares here are some statistics.  I grabbed lkml
traffic from early january to early feburary, and looked at all the
multi message patches and split them into the 3 categories split,
shallow and deep.  That means:

  Split: (multiple seperate threads)
  foobar patch 1
  +-comment on patch 1
  foobar patch 2
  foobar patch 3
  +-comment on patch 3
  foobar patch 4
  foobar patch 5

  Shallow: (A tree of patches, with all patches linked from a single start message)
  foobar patch 0 (usually a summary/overview)
  +-foobar patch 1
  | +-comment on patch 1
  +-foobar patch 2
  +-foobar patch 3
  | +-comment on patch 3
  +-foobar patch 4
  +-foobar patch 5

  Deep: (One long chain of patches)
  foobar patch 0
  +-foobar patch 1
    +-foobar patch 2
    | +-foobar patch 3
    |   +-foobar patch 4
    |   | +-foobar patch 5
    |   +-comment on patch 3
    +-comment on patch 1

So the results were that people had used:
Split: 25 patch sets.
Shallow: 56 patch sets.
Deep: 6 patch sets.

It certainly looks like the shallow threaded mode is by far the most
prefered style by kernel developers, and should perhaps be the default
in GIT, especially given it makes it harder to follow the thread (later
patches are seen before comments on a patch, and the thread gets very
wide on the screen.  I suspect almost all if not all of the users of the
default deep method, do it because its the default and not by choice.  I
doubt whoever implemented the feature in git had even though about what
would happen when someone did a 50 part patch set that way.  It may even
be that some people use the split style because they don't like the deep
style and git doesn't support doing the shalow style that most people
prefer.

Fortunately the people responsible for posting the largest patch sets
(such as stable reviews and the like) are doing it with shallow stule
already, however they manage to do that.  Yay!

Oh well, back to doing actual useful work again...

-- 
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/