Re: [alsa-devel] HG -> GIT migration

From: Takashi Iwai
Date: Wed May 21 2008 - 17:09:04 EST

At Wed, 21 May 2008 12:02:29 -0700 (PDT),
Linus Torvalds wrote:
> On Wed, 21 May 2008, Takashi Iwai wrote:
> >
> > > - cherry-pick it. Is it a small, simple patch that you want, but that
> > > isn't really worth pulling in all the other stuff that you simply don't
> > > know?
> > >
> > > This isn't wrong. It shouldn't be *common*, but it's not wrong to have
> > > the same patch in two different branches. It makes sense if it is
> > > something you really want, but it's still not important or complex
> > > enough to actually mege everything else!
> >
> > Hm, that's what I didn't consider seriously. I thought cherry-picking
> > patches may cause merge errors easily.
> Cherry-picking can certainly cause merge errors, but not generally very
> often.
> Cherry-picking by definition will obviously apply the *same* patch to two
> different branches, and as a result, when you merge, that merge will
> generally be totally clean. So a trivial merge that succeeds without you
> even noticing is actually the common case.
> But you can certainly get merge failures where you then have to fix things
> up if there were *other* changes to that same area. At that point, you end
> up with two different branches that changed the same few lines
> differently, and it doesn't matter if then _some_ of the changes were
> identical - the fact that others were not is enough to cause a merge
> conflict.
> If cherry-picking is an uncommon situation, the merge problems are not
> going to show up (and when they do, they'll generally be simple to
> resolve, especially if you limit cherry-picking to simple fixes). But if
> you do a *lot* of cherry-picking, and you cherry-pick big changes, then
> yes, you'll start hitting merge problems.
> So cherry-picking is fine if you do it (a) fairly seldom and (b) just to
> small patches, because then the upsides of cherry-picking (easy to get a
> single fix without merging everything else) are bigger than the downsides
> (the potential merge problems later).
> IOW, think of cherry-picking as just another tool. It has upsides and
> downsides. It's not "wrong" per se, but you can use it the wrong way. You
> shouldn't use a hammer on a screw, and you shouldn't use cherry-picking
> for big and complex stuff.

Thanks for clarification!

Sounds like I should really do this more often to keep the devel tree
clean without merge or rebase.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at