mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Adrian Bunk <bunk@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Harvey Harrison <harvey.harrison@gmail.com>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: If you want me to quit I will quit
Date: Sat, 26 Apr 2008 10:31:36 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0804261024580.2813@woody.linux-foundation.org> (raw)
In-Reply-To: <20080426171604.GN2252@cs181133002.pp.htv.fi>



On Sat, 26 Apr 2008, Adrian Bunk wrote:
> On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
> >...
> > git-tree owners might need, umm, some encouragement here.  It's much easier
> > for them to slap the oh-let's-fix-that-up commit at the tail of their
> > queue, which leaves us with the straggly commit record.
> 
> As far as I understand Linus on these matters people David Miller 
> mustn't edit older commits in their trees once their tree got pushed 
> out.

I wouldn't say "mustn't", because the _one_ thing I hate is totally rigid 
rules. 

What I do try to encourage is for people to think publicising their git 
trees as "version announcements". They're obviously _development_ 
versions, but they're still real versions, and before you publicize them 
you should try to make sure that they make sense and are something you can 
stand behind.

And once you've publicized them, you don't know who has that tree, so just 
from a sanity and debugging standpoint, you should try to avoid mucking 
with already-public versions. If you made a mistake, add a patch on top to 
fix it (and announce the new state), but generally try to not "hide" the 
fact that the state has changed.

But it's not a hard rule. Sometimes simple cleanliness means that you can 
decide to go "oops, that was *really* wrong, let's just throw that away 
and do a whole new set of patches". But it should be something rare - not 
normal coding practice.

Because if it becomes normal coding practice, now people cannot work with 
you sanely any more (ie some random person pulls your tree for testing, 
and then I pull it at some other time, and the tester reports a problem, 
but now the commits he is talking about don't actually even exist in my 
tree any more, and it's all really messy!).

The x86 tree still does this. I absolutely detest it. Ingo claims that his 
model is better, and I'm pretty damn sure he's wrong. But until it starts 
causing bigger problems, I'll give him the benefit of the doubt.

				Linus

  parent reply	other threads:[~2008-04-26 17:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-26  6:14 [BUILDFIX PATCH] au0828: debug is a poor global identifier Harvey Harrison
2008-04-26 11:00 ` If you want me to quit I will quit Adrian Bunk
2008-04-26 11:27   ` Sam Ravnborg
2008-04-26 14:44     ` Adrian Bunk
2008-04-26 16:51       ` Linus Torvalds
2008-04-26 17:09         ` Adrian Bunk
2008-04-26 17:21           ` Linus Torvalds
2008-04-26 17:35             ` Adrian Bunk
2008-04-26 17:56               ` Linus Torvalds
2008-04-26 14:51   ` Andrew Morton
2008-04-26 15:23     ` Adrian Bunk
2008-04-26 15:44       ` Andrew Morton
2008-04-26 17:16         ` Adrian Bunk
2008-04-26 17:20           ` Andrew Morton
2008-04-26 17:27             ` Adrian Bunk
2008-04-26 17:35               ` Linus Torvalds
2008-04-26 17:31           ` Linus Torvalds [this message]
2008-04-26 17:42             ` Sam Ravnborg
2008-04-26 18:26               ` Linus Torvalds
2008-04-26 18:51             ` Stefan Richter
2008-04-26 19:05               ` Linus Torvalds
2008-04-26 19:18                 ` Linus Torvalds
2008-04-26 20:30                   ` Andrew Morton
2008-04-26 20:35                     ` Linus Torvalds
2008-04-28 19:05                       ` Romano Giannetti
2008-04-26 20:49                     ` Stefan Richter
2008-04-27 12:07                     ` Richard Purdie
2008-04-27 14:28                       ` Stefan Richter
2008-04-26 19:43                 ` Stefan Richter
2008-04-27  0:31             ` David Miller
2008-04-27  2:58               ` Jeff Garzik
2008-04-27 16:09             ` Ingo Molnar
2008-04-26 16:21   ` Bartlomiej Zolnierkiewicz
2008-04-26 17:10   ` Adrian Bunk
2008-04-26 19:20   ` Harvey Harrison
2008-04-26 19:42     ` Adrian Bunk

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=alpine.LFD.1.10.0804261024580.2813@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=harvey.harrison@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@infradead.org \
    /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

Powered by JetHome