Why does git merge have so much trouble with Fedora package branches?

[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.

--
Vratislav Podzimek

Anaconda Rider
Red Hat, Inc. | Brno, Czech Republic