From: Rene Herman <rene.herman@keyaccess.nl>
To: Takashi Iwai <tiwai@suse.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
ALSA development <alsa-devel@alsa-project.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: HG -> GIT migration
Date: Wed, 21 May 2008 17:29:56 +0200 [thread overview]
Message-ID: <48343FF4.8090107@keyaccess.nl> (raw)
In-Reply-To: <s5h8wy3wvyv.wl%tiwai@suse.de>
On 21-05-08 16:52, Takashi Iwai wrote:
> At Wed, 21 May 2008 16:40:37 +0200,
> Rene Herman wrote:
>> I'm also still frequently trying to figure out an/the efficient way of
>> using GIT but it does seem it's not just a matter of "pure downstream"
>> (which I do believe ALSA has few enough of to not make this be a huge
>> problem). For example linux-next is also going to want to pull in ALSA
>> and say it does, finds a trivial conflict with the trivial tree that it
>> also pulls in and fixes things up. If you rebase that which linux-next
>> pulls from I believe it will have to redo the fix next time it pulls
>> from you since it's getting all those new changesets.
>>
>> I guess this can be avoided by just not rebasing that which linux-next
>> is pulling... and I in fact don't even know if linux-next does any
>> conflict resolution itself, trivial or otherwise.
>
> I thought linux-next does fresh merges at each time, thus it doesn't
> matter whether a subsystem tree is rebased or not...
Let's ask...
Fresh merges at each release boundary certainly but if it drops/remerges
each subsystem when a bug in its for-next branch is found (a supposedly
non rare occurence) all the hopefully hundreds or even thousands of
linux-next pullers/testers would seem to have to deal with all those
completely new merges everytime as well. I'd hope linux-next during a
single release would just pull in the one fix (the subsystem's for-linus
branch can still fold it in).
Rene.
WARNING: multiple messages have this Message-ID (diff)
From: Rene Herman <rene.herman@keyaccess.nl>
To: Takashi Iwai <tiwai@suse.de>
Cc: Jaroslav Kysela <perex@perex.cz>,
ALSA development <alsa-devel@alsa-project.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [alsa-devel] HG -> GIT migration
Date: Wed, 21 May 2008 17:29:56 +0200 [thread overview]
Message-ID: <48343FF4.8090107@keyaccess.nl> (raw)
In-Reply-To: <s5h8wy3wvyv.wl%tiwai@suse.de>
On 21-05-08 16:52, Takashi Iwai wrote:
> At Wed, 21 May 2008 16:40:37 +0200,
> Rene Herman wrote:
>> I'm also still frequently trying to figure out an/the efficient way of
>> using GIT but it does seem it's not just a matter of "pure downstream"
>> (which I do believe ALSA has few enough of to not make this be a huge
>> problem). For example linux-next is also going to want to pull in ALSA
>> and say it does, finds a trivial conflict with the trivial tree that it
>> also pulls in and fixes things up. If you rebase that which linux-next
>> pulls from I believe it will have to redo the fix next time it pulls
>> from you since it's getting all those new changesets.
>>
>> I guess this can be avoided by just not rebasing that which linux-next
>> is pulling... and I in fact don't even know if linux-next does any
>> conflict resolution itself, trivial or otherwise.
>
> I thought linux-next does fresh merges at each time, thus it doesn't
> matter whether a subsystem tree is rebased or not...
Let's ask...
Fresh merges at each release boundary certainly but if it drops/remerges
each subsystem when a bug in its for-next branch is found (a supposedly
non rare occurence) all the hopefully hundreds or even thousands of
linux-next pullers/testers would seem to have to deal with all those
completely new merges everytime as well. I'd hope linux-next during a
single release would just pull in the one fix (the subsystem's for-linus
branch can still fold it in).
Rene.
next prev parent reply other threads:[~2008-05-21 15:27 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 11:21 HG -> GIT migration Jaroslav Kysela
2008-05-20 14:12 ` Ben Stanley
2008-05-20 14:24 ` Jaroslav Kysela
2008-05-21 2:30 ` Eliot Blennerhassett
2008-05-21 6:09 ` Jaroslav Kysela
2008-05-21 10:28 ` Takashi Iwai
2008-05-21 12:30 ` Rene Herman
2008-05-21 12:37 ` Takashi Iwai
2008-05-21 13:04 ` Rene Herman
2008-05-21 13:04 ` [alsa-devel] " Rene Herman
2008-05-21 13:48 ` Jaroslav Kysela
2008-05-21 14:40 ` Rene Herman
2008-05-21 14:40 ` [alsa-devel] " Rene Herman
2008-05-21 14:52 ` Takashi Iwai
2008-05-21 14:52 ` [alsa-devel] " Takashi Iwai
2008-05-21 15:29 ` Rene Herman [this message]
2008-05-21 15:29 ` Rene Herman
2008-05-22 1:24 ` Stephen Rothwell
2008-05-22 20:43 ` Rene Herman
2008-05-22 20:43 ` [alsa-devel] " Rene Herman
2008-05-22 23:40 ` Stephen Rothwell
2008-05-22 23:40 ` [alsa-devel] " Stephen Rothwell
2008-05-21 14:47 ` Takashi Iwai
2008-05-21 14:47 ` [alsa-devel] " Takashi Iwai
2008-05-21 15:40 ` Rene Herman
2008-05-21 15:40 ` [alsa-devel] " Rene Herman
2008-05-21 16:02 ` Takashi Iwai
2008-05-21 16:02 ` [alsa-devel] " Takashi Iwai
2008-05-21 16:16 ` Linus Torvalds
2008-05-21 16:51 ` Takashi Iwai
2008-05-21 16:51 ` [alsa-devel] " Takashi Iwai
2008-05-21 17:07 ` Tobin Davis
2008-05-21 17:19 ` Jaroslav Kysela
2008-05-21 17:22 ` Rene Herman
2008-05-21 17:43 ` [alsa-devel] " Linus Torvalds
2008-05-21 18:11 ` Linus Torvalds
2008-05-21 18:11 ` [alsa-devel] " Linus Torvalds
2008-05-21 18:25 ` david
2008-05-21 18:39 ` Linus Torvalds
2008-05-21 18:39 ` [alsa-devel] " Linus Torvalds
2008-05-21 18:49 ` Takashi Iwai
2008-05-21 18:49 ` [alsa-devel] " Takashi Iwai
2008-05-21 18:47 ` Takashi Iwai
2008-05-21 18:47 ` [alsa-devel] " Takashi Iwai
2008-05-21 19:02 ` Linus Torvalds
2008-05-21 19:02 ` [alsa-devel] " Linus Torvalds
2008-05-21 21:08 ` Takashi Iwai
2008-05-21 21:08 ` [alsa-devel] " Takashi Iwai
2008-05-22 14:23 ` Dmitry Torokhov
2008-05-21 22:16 ` Eliot Blennerhassett
2008-05-23 2:31 ` Ben Stanley
2008-05-23 6:38 ` Jaroslav Kysela
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=48343FF4.8090107@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=tiwai@suse.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.