> At Wed, 21 May 2008 15:04:53 +0200,
> Rene Herman wrote:
> >
> > On 21-05-08 14:37, Takashi Iwai wrote:
> >
> > > At Wed, 21 May 2008 14:30:31 +0200,
> > > Rene Herman wrote:
> >
> > >> $ git remote show sound-2.6
> > >> * remote sound-2.6
> > >> URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > >> Tracked remote branches
> > >> master
> > >>
> > >> What's the status of that one now? Should I continue pulling that one or
> > >> should I switch to the new alsa-kernel GIT repo? I want to pull it into
> > >> a Linus clone tree...
> > >
> > > We are working on this right now. alsa.git is far currently behind my
> > > tree.
> > >
> > > One problem we hit is about multiple committers and rebase. If you do
> > > git-rebase, the commiter information is touched although the sign-off
> > > isn't updated. git-rebase looks apparently designed for the
> > > single-commiter model.
> >
> > It's "worse" than that; rebasing is designed for a _private_ development
> > model. git-rebase is a very handy tool for people like myself (people
> > without a downstream that is) and it basically enables the quilt model
> > of a stack of patches on top of git but public trees that have people
> > pulling from them should generally not rebase or everyone who _is_
> > pulling finds a different tree each time.
> >
> > Linus is vehement about this also. There have a few threads about it and
> > the most recent was:
> >
> >
http://lkml.org/lkml/2008/5/17/190
> >
> > I'm also not an experienced git user (not other than in my own leafnode
> > developer mode, certainly) but I expect Linus might not terribly mind
> > answering a few questions about the model -- ALSA is a significant
> > subsystem and it switching to GIT might even make for a nice "this is
> > how you do that as a subsystem" treatise...
> >
> > (ie, also added linux-kernel)
>
> 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...
>
