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

Adam Williamson awilliam at redhat.com
Thu Nov 10 19:59:50 UTC 2011


On Thu, 2011-11-10 at 08:55 -0800, Toshio Kuratomi wrote:
> On Thu, Nov 10, 2011 at 09:02:45AM -0500, Simo Sorce wrote:
> > On Thu, 2011-11-10 at 13:27 +0100, Michael J Gruber wrote:
> > > I'm sorry but the reason is that people don't know git workflows.
> > 
> > I guess it depends on what is the maintainer preferred workflow.
> > 
> > I personally hate git merge, especially for stuff so simple as fedora
> > trees. It gives no advantages I can see to the way I work and causes
> > quite a lot of bad side-issues.
> > 
> > [..]
> >
> I've found git cherry-pick hard to use compared to git merge -- but then
> again, I'm using cherry-pick to actually cherry-pick; not keep two branches
> in sync.
> 
> So if my usual workflow is commit to master, test, commit, test, then
> make fX equivalent to master and build there, what is the cherry-pick way to
> do that simple task?
> 
> git merge way would be:
> 
> $ git checkout f16
> $ git merge master
> 
> which seems very simple and very suited for this particular workflow.

As I've understood the thread so far that's fine - so long as you
actually want master and f16 to be the same, of course. I'm not sure
what you're supposed to do when master has a later version of the
package than f16, but you want to introduce some other change to both
branches, for e.g.

My problem came in the case where someone has already *not* done this -
they've updated f16 separately from, and more than, master, and I wanted
to get them back in sync.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the devel mailing list