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

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: <s5h1w3v1i1q.wl%tiwai@suse.de>
Date:	Wed, 21 May 2008 23:08:49 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Rene Herman <rene.herman@...access.nl>,
	alsa-devel@...a-project.org,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] HG -> GIT migration

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.


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