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

[Michael J Gruber]

Adam Williamson venit, vidit, dixit 10.11.2011 02:46:
> 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.
> 
> Take the current state of gnome-power-manager. Master is at:
> 
> commit dfd0f074a7d41d355da28180eae1bda5dc2bba66
> Author: Richard Hughes <richard at hughsie.com>
> Date:   Mon Sep 26 16:58:28 2011 +0100
> 
>     New upstream version.
> 
> f16 is at:
> 
> commit b0b31219d2cfdffa815659a8aad78509b65c412a
> Author: Richard Hughes <richard at hughsie.com>
> Date:   Mon Oct 17 11:34:50 2011 +0100
> 
>     New upstream version.
> 
> which is just a single commit ahead of the master branch. The git diff
> is incredibly trivial:
> 
> [adamw at adam gnome-power-manager (f16)]$ git diff dfd0f074a7d41d355da28180eae1bda5dc2bba66
> diff --git a/.gitignore b/.gitignore
> index 7cf4a61..b9cba18 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -15,3 +15,4 @@ gnome-power-manager-2.31.4.tar.bz2
>  /gnome-power-manager-3.1.90.tar.xz
>  /gnome-power-manager-3.1.92.tar.xz
>  /gnome-power-manager-3.2.0.tar.xz
> +/gnome-power-manager-3.2.1.tar.xz
> diff --git a/gnome-power-manager.spec b/gnome-power-manager.spec
> index cba83e2..e5a512f 100644
> --- a/gnome-power-manager.spec
> +++ b/gnome-power-manager.spec
> @@ -1,6 +1,6 @@
>  Summary: GNOME power management service
>  Name: gnome-power-manager
> -Version: 3.2.0
> +Version: 3.2.1
>  Release: 1%{?dist}
>  License: GPLv2+ and GFDL
>  Group: Applications/System
> @@ -75,6 +75,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null
>  %{_mandir}/man1/*.1.gz
>  
>  %changelog
> +* Mon Oct 17 2011 Richard Hughes <rhughes at redhat.com> - 3.2.1-1
> +- New upstream version.
> +
>  * Mon Sep 26 2011 Richard Hughes <rhughes at redhat.com> - 3.2.0-1
>  - New upstream version.
>  
> diff --git a/sources b/sources
> index 81e4f0f..2d18e7f 100644
> --- a/sources
> +++ b/sources
> @@ -1 +1 @@
> -4dafea2ae923599685f91de033f23888  gnome-power-manager-3.2.0.tar.xz
> +8e8a3759e0805041342c1f49471ee4ed  gnome-power-manager-3.2.1.tar.xz
> 
> 
> But if you try and do a merge:
> 
> [adamw at adam gnome-power-manager (master)]$ git merge --no-ff b0b31219d2cfdffa815659a8aad78509b65c412a
> Auto-merging sources
> CONFLICT (content): Merge conflict in sources
> Auto-merging gnome-power-manager.spec
> CONFLICT (content): Merge conflict in gnome-power-manager.spec
> Auto-merging .gitignore
> CONFLICT (content): Merge conflict in .gitignore
> Automatic merge failed; fix conflicts and then commit the result.
> 
> why the conflict? Why can it not merge this incredibly simple version
> bump? I guess I'm just missing something about how git works, but I
> can't really see why this causes a problem.
> 
> It's rather infuriating to have to go in and 'fix' a bunch of
> 'conflicts' which are not conflicts at all, but just the changes you
> wanted to merge with a bunch of silly >>>> and <<<< around them.

I'm sorry but the reason is that people don't know git workflows. Many
fedora repos have a crappy history: Even the Fedora guidelines say you
should commit changes to master and merge them down to release branches
one (branch) by one. Some of those histories are due to the import from
cvs times, of course, but some are new.

If you look at gnome-power-manager you see that starting from the fork
point 1b8c97a, origin/f16 and origin/master have diverged by applying
the same patches separately to both branches, rather then applying them
on master and merging them to f16. Actually, it's hard to see, because
the commit messages are crappy also... With the current state (merge at
origin/master):

git log --oneline  --cherry-mark origin/f16...origin/master^
+ b0b3121 New upstream version.
= d13e256 New upstream version.
= dfd0f07 New upstream version.
= 6d8cf84 New upstream version.
= b16cb9b New upstream version.
= 4e66202 Fix an error in the postun scriptlet Require
gnome-settings-daemon as we use its schema.
= 7e353a1 Fix an error in the postun scriptlet Require
gnome-settings-daemon as we use its schema.
= 17e071c g-s-d is a runtime dep, not a buildtime dep
= 4a083bd g-s-d is a runtime dep, not a buildtime dep
= acf3bc4 Add BR gnome-settings-daemon
= 05641e6 Add BR gnome-settings-daemon
= 380709b New upstream version.
= aab8201 New upstream version.

Tons of equivalent, but different patches. Only one non-equivalent
patch. (What keeps one from saying which new upstream version...?) But
by its very nature, a merge cannot "coalesce" different equivalent
patches, only a rebase would. A merge gives conflicts because as
compared to the fork point (merge base), both branches change the same
lines in different ways (e.g. the sources file).

Mixing cherry-picks and merges almost inevitably leads to these problems.

In this situation, cherry-picking b0b3121 from origin/f16 to master
would have been the best fixup for the crappy history. After that, both
diverging branches are "equivalent", and a merge from master to
origin/f16 would have succeeded with the default recursive strategy and
without any conflicts.

Hmm, do I sound like ranting? I hope not, or else sorry, I'd be barking
up the wrong tree. In any case I hope this post helps.

Cheers,
Michael