linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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]

Message-ID: <alpine.LFD.1.00.0802120945290.2920@woody.linux-foundation.org>
Date:	Tue, 12 Feb 2008 10:00:38 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))



On Tue, 12 Feb 2008, James Bottomley wrote:
>
> On Tue, 2008-02-12 at 09:09 -0800, Linus Torvalds wrote:
> >  (a) create a base tree with _just_ that fundamental infrastructure change,
> >      and make sure that base branch is so obviously good that there is no 
> >      question about merging it.
> 
> The problem is how do we use a?  Usually we need to track your -rc tree
> as our fixes go in ... some of which affect our development trees.

So?

> If we stick with (a) as the base, we don't get to pull in the fixes in
> your tree.  If we use your tree we have to pull in (a) creating n
> different merge points for the n different upstream trees..

I don't understand what you mean. This is true whether you pulled (a) or 
not. If you have any changes what-so-ever in your tree, if you pull in 
fixes from my tree, you'll get a merge.

But if you mean that you cannot rebase (a), then yes. That was what I 
said. Rebases *do*not*work* (and fundamentally cannot work) in a 
distributed environment.

But why would you merge with my tree in the first place? My tree won't 
normally have any conflicts or anything like that anyway.

With a "Linux-next" tree, you'll see the conflicts if they occur (since 
*that* tree would merge!), and in that case you would say  "now I need to 
merge Linus' tree just to resolve the conflicts!"

But before that, merging my tree (or rebasing on top of it) is simply 
*wrong*. It has nothing to do with your SCSI development.

> Yes, this is effectively what I did with the post merge SCSI tree.
> However, if you do this rebasing becomes a fact of life because you need
> to rebase out all the dependencies you have before you merge (in fact,
> it's a good way of checking whether your dependencies have been merged
> yet or not, seeing what survives a rebase).

I don't see the logic. You shouldn't need to rebase at all. I don't see 
why you claim that this makes rebasing more of a fact. It doesn't. It has 
no impact at all, except making rebasing _less_ possible!

		Linus
--
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/