Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek: > On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote: > > On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote: > > > On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote: > > > > On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote: > > > > > I'm currently going through and bumping several packages whose Rawhide > > > > > builds have got behind their F16 builds. > > > > > > > > > > I've come across several packages where git merge hit 'conflicts' for no > > > > > readily apparently reason in this case. > > > > > > > > I haven't looked deeply enough to tell, but in general merges are a very > > > > bad tool and should be avoid IMHO. > > > > > > > > It would be much more sane to git cherry-pick the changes you need and > > > > keep the branches separate and have their own history. > > > > Merges makes it really painful to follow history later. > > > > > > I agree. Once branches have started to diverge, merging them makes the > > > history harder to follow because the branches keep diverging, merging > > > back, diverging again, merging,... > > > > > > However, it is sometimes possible to never diverge. > > > > > > In the example of gnome-power-manager, the master and f16 branches seem > > > to contain the exact same changes, in the same order. > > > > > > In such a case, it would have made sense to always keep merging the > > > branches rather than cherry-picking, so that they would never have > > > diverged. > > > > > > And that would have avoided the conflict Adam is seeing. > > > > thanks both of you; I hadn't really thought about the consequences of > > merging vs. cherry-picking, I think I'd just cargo-culted from somewhere > > the idea of using git merge instead of manually re-doing changes without > > considering cherry-picking instead. so I guess in general it's both a > > better idea and more likely to work to use cherry-pick instead of merge, > > unless the two branches are really expected to be identical? > Isn't it better to use 'git rebase'? E.g. on master use 'git rebase > f16'. As I understand it, it would do the same as cherry-picking commit > after commit in these cases. Someone might correct me, but rebasing introduces problems for co-maintainers, if upstream (maintainer) decides to rebase some branch. See http://man.he.net/man1/git-rebase - fabian -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
