WARNING: Git merges are tricky. Rebasing is better?

[Leo Famulari <leo@famulari.name>]

Take note that Git merges can be tricky and hide mistakes! Please
consider using a rebasing workflow instead of a merging workflow for
your branches.

For example, today we merged the version-1.4.0 branch into the master
branch, with commit 276f40fdc349d2ad62582b23ea55e061b689cfc0.

After the merge, we got a report on the #guix IRC channel [0] that the
Epiphany package's source hash was incorrect. It was using the hash of
the previously packaged version of Epiphany.

Using Git, we can see that in commit 291c4fa0ba, Epiphany was updated to
version 41.2, with a correct change in hash:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=291c4fa0baf24b9d600872fce99441f5471cdb40

Later, the version-1.4.0 branch was merged into master.

View the Git log from the commit where Epiphany was updated through the
merge:

$ git log --patch 291c4fa0baf^..276f40fdc34 gnu/packages/gnome.scm

It does not show that the update of Epiphany's source hash was reverted.

And to be sure that something is wrong, we can examine the file based on
the merge commit:

------
$ git show 276f40fdc349d2ad62582b23ea55e061b689cfc0:gnu/packages/gnome.scm | grep "define-public epiphany" -A11
(define-public epiphany
  (package
    (name "epiphany")
    (version "41.2")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnome/sources/epiphany/"
                                  (version-major version) "/"
                                  "epiphany-" version ".tar.xz"))
              (sha256
               (base32
                "0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
------           ^
                *This is the hash of Epiphany 40.3, the old version!*

Git's automatic merge conflict resolution algorithm did the wrong thing
here. And Git does not show the reversion in `git log`, hiding it from
review.

My guess is that commit f7afefba0 ("gnu: epiphany: Fix build with
libportal-0.5."), which happened on the master branch while the
version-1.4.0 branch was forked off, made Git think that this line was
more "up to date" on master than on version-1.4.0, causing it to select
the old hash when faced with the conflict.

Once again, consider using a workflow based on rebasing instead of
merging for forked branches that will live for weeks to a month or two.
This type of mistake cannot be obscured when rebasing.

[0] http://logs.guix.gnu.org/guix/2022-01-17.log#195313