From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935626AbYEUQCl (ORCPT ); Wed, 21 May 2008 12:02:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759144AbYEUQCb (ORCPT ); Wed, 21 May 2008 12:02:31 -0400 Received: from mail.suse.de ([195.135.220.2]:45805 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758149AbYEUQCa (ORCPT ); Wed, 21 May 2008 12:02:30 -0400 Date: Wed, 21 May 2008 18:02:28 +0200 Message-ID: From: Takashi Iwai To: Rene Herman Cc: alsa-devel@alsa-project.org, Linus Torvalds , Linux Kernel Subject: Re: [alsa-devel] HG -> GIT migration In-Reply-To: <48344271.3090700@keyaccess.nl> References: <200805211430.06653.linux@audioscience.com> <483415E7.5080402@keyaccess.nl> <48341DF5.4090307@keyaccess.nl> <48344271.3090700@keyaccess.nl> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 21 May 2008 17:40:33 +0200, Rene Herman wrote: > > On 21-05-08 16:47, Takashi Iwai wrote: > > > Theoretically we can work only using merges. However, the resultant > > tree will look too complex with lots of merge points at the time of > > the next merge window. This is also a nightmare for bisecting. Thus, > > most subsystem trees do rebase before the merge window in practice, > > AFAIK. > > > > It'd be appreciated if someone can tell me any good workflow to keep a > > good-shaped tree without rebasing... > > Over here: > > http://lkml.org/lkml/2008/5/17/203 > > Linus suggests to just not do many merges from upstream -- basically > only at releases. But, this means that the fixes done outside the subsystem tree cannot be in the subsystem tree itself until the next release. It's a pretty weird situation. Of course, we can do cherry-pick each fix in the upstream, but it doesn't work always, too. Suppose a fix that uses a newly introduced API after the merge window, which doesn't exist in the subsystem tree yet. Or, if you want add new patches during the merge window, etc. The method Linus suggested is suitable for random patches like tirival tree, but apparently not for every case. Takashi