"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Christian Weisgerber <naddy@mips.inka.de>
Subject:
Landry's firefox repository
To:
gameoftrees@openbsd.org
Date:
Tue, 30 Jan 2024 21:43:01 +0100

Download raw body.

Thread
(This is me again musing about something that didn't work as expected
for me, but I don't know to what degree that's a bug, much less
what to do about it.)

Landry keeps a publically readable git repository for the OpenBSD
www/mozilla-firefox port, where he also tracks the beta releases:
https://cgit.rhaalovely.net/mozilla-firefox/

That requires git(1) for cloning/fetching because of https, but
apart from that I tried using a got checkout... and ran into the
problem that the usual "got up -b origin/master && got rb master"
dance threw conflicts at me even though there were no local commits.
Huh.

To reproduce:

  # get and prepare repository
  git clone --bare https://cgit.rhaalovely.net/mozilla-firefox/
  cd mozilla-firefox.git
  git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
  git fetch

  cd ..
  got co -b origin/master mozilla-firefox.git
  cd mozilla-firefox
  # reset master to an earlier commit where it once was
  got ref -c 9cd4661e4c refs/heads/master
  # try rebasing (fast forwarding) this to the new tip
  got rb master
  C  Makefile
  C  distinfo
  Files with new merge conflicts: 2
  4e6975f4a13f -> merge conflict: 121.0.1
  got: conflicts must be resolved before rebasing can continue

Looking at this with "git log --graph", I see that landry@ has
a branch "master" for release versions and a branch "beta" for
beta versions.  If there are intermediate point releases, those
go to "master", which is then partially merged into beta.  Each
new major release, "beta" is apparently renamed to "master" and
a new "beta" branch is created.

With --graph, the first parent history of "master" is actually that
of "beta", and "master" is a parallel branch that is merged as the
second parent.  The result is that "got rebase" of an older "master"
branch on "origin/master" can fail.  I also tried "got up -b master
&& got mg origin/master" and that succeeded and performed the
expected fast forward.

I briefly checked and git(1) handles this case fine for both "rebase"
and "merge".

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de