Question on (my) workflow migration svn -> git

[David Wolfskill]

On Mon, Oct 05, 2020 at 05:03:12PM +0200, Ulrich Spörlein wrote:
> ...
> > Sure -- and I (at least half-)expected that: I am experimenting, so at
> > this stage, I expect a loty of stuff to be tried and tossed.
> 
> David, I'm not sure what "unhappiness" you were referring to. I just
> updated the bare repo from my stable_12 worktree that I've created last
> time.

Unfortunately, I failed to run it within script(1), so I don't have a
record, but the attempt to fetch (on the "bare" (but not "mirror") repo
failed.

As noted, when I re-created the repo, I created it as a "mirror"...
which (based on your comments beliw) appears to have been a fairly
reasonable thing to do. :-)

> ...
> What I tried:
> 
> % cd /tmp/stable_12
> % git fetch   # takes some time, downloads 1GiB ...
> Receiving objects: 100% (2734600/2734600), 1.04 GiB | 2.90 MiB/s, done.
> Resolving deltas: 100% (2119516/2119516), completed with 368 local objects.
> From https://cgit-beta.freebsd.org/src
>  * branch                    HEAD       -> FETCH_HEAD
> 
> This is a bit worrying, as it did not update any of the refs, so it's
> borderline useless. A `git pull` instead of fetch will spew out a grant
> massive diff though and churn like mad. ^C ^C
> 
> So we need to properly update our "upstream" bare repo first:
> % cd /tmp/src.git
> % git fetch -pP
> 
> That downloads everything again, which isn't surprising as it doesn't
> know about all the other refs that were already fetched, and also
> because the server offers that all in 1 giant packfile and I guess it
> doesn't re-compress and encode things on the fly :/
> 
> Turns out that refuses to clobber existing tags, so I run it again with
> --force. Still no luck with refs, turns out this wasn't a --mirror
> clone, so I add `mirror = true` and `fetch = +refs/*:refs/*` under its
> remote section.

Aye; I had noted the parts (from "git help clone") about how "--mirror"
handles all branches and refs, and figured that would be a Good Thing
for my use case.

> % git fetch --force --all
> ...
> aaahh, that finally gets me all the refs into a proper mirror bare repo.

:-)  So far (2 out of 2 tries, so take it with a "grain of salt") mere
"git fetch --all" seems to be adequate for the mirror repo.

> Back to stable/12 workspace and force a checkout to stable/12, even
> though due to hash re-spinning it is something "totally" unrelated.
> 
> % cd /tmp/stable_12
> % git status  # will list how we are so, so different from what is now
>               # stable/12 in our local upstream bare repo that we share
>               # refs with
> % git reset --hard stable/12   # yolo, get us stable/12 no matter what
>                                # we have to throw away

In practice, I find that I do not need to specify the target branch --
just "git reset --hard" appears to be adequate.

> So there you have it. No need to throw away your existing bare repo, but
> starting out with a --mirror clone would've made things easier.

So I am seeing.  So it's good that this is documented, after a fashion.

> Then you need to keep in mind git never wants to throw away any diffs
> you might have, and we might get 1 or 2 more massive "diffs" due to
> different hashes till the final switch over date.

Aye.  For now, I'll:

* Continue using svn for actually updating the sources I use to keep my
  systems up-to-date.

* Experiment with setting something up to update my local private git
  mirror repo on a daily basis, as well.

* Start running some comparisonsa -- and, with luck, build some
  confidence that the use of git may work for me.

> As you want a read-only mirror/checkout of this, you can just forcefully
> `reset --hard` the workspace to whatever git hash or reference you
> fancy.

Well, the mirror repo is read-only.  I do mess with the working copy
(e.g. for experimenting with patches after I've reported an issue).

I also rely on having mt kernel config file represented in the source
tree by a symlink to a different hierachy of files under separate
revision control, so that could also prove to become "interesting."
> 
> > > Deleting and cloning again from scratch is a reasonable way to
> > > interact with the repository during this stage.
> > ...
> > > For the time being I think that you'd want to remove the bare repo and
> > > worktrees, and recreate everything from scratch over a hash change.
> 
> Not really required, but you need to understand the data model to be
> able to dig your clone out of that mess.

Fair, but given that it was a "scratch" repo anyway, blowing the old one
away and re-creating (as a real "mirror") appears to have worked well in
this case.

> > And that part's fine.
> > 
> > Where I'm having a problem is for the (usual) case of "no hash change",
> > but there have been commits to the source-of-truth: it appears that "git
> > fetch --all" copies those to my local private mirror, but I don't see
> > how to get my "worktree" updated.
> 
> In your stable_12 workspace, you should be able to do this normally with
> `git pull origin stable/12`, but that is a) not going to work while we
> respin hashes and b) overkill, as you don't even want any of the
> safeguards. So in short:
> 
> - in your bare --mirror clone: git fetch (--force)

Aye.

> - in your workspace: git reset --hard stable/12

Aye (though as noted above, the target branch appears to be superfluous).

> This is not expected to make sense

That is actually a fairly large relief to see.... :-}

> Uli

Thanks again -- I think we're actually closing in on a solution (for my
case).

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
"the end of the pandemic is in sight" -- Donald Trump (while infected
with SARS-COV-2)

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20201005/a6e98158/attachment.sig>