Date: Mon, 5 Oct 2020 17:03:12 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@freebsd.org> To: David Wolfskill <david@catwhisker.org> Cc: Ed Maste <emaste@freebsd.org>, git@freebsd.org Subject: Re: Question on (my) workflow migration svn -> git Message-ID: <20201005150312.GQ92039@acme.spoerlein.net> In-Reply-To: <20201004180342.GB1349@albert.catwhisker.org> References: <20200924201715.GR1390@albert.catwhisker.org> <20200924205326.GB64154@spindle.one-eyed-alien.net> <CAJ9axoR=0zPxUSF-wH-ZT%2BeeHN3-ZB%2B=M6NcbWR1zKncU2m%2BKA@mail.gmail.com> <20200926020946.GK1390@albert.catwhisker.org> <20200926124212.GL92039@acme.spoerlein.net> <20201003223531.GA77534@albert.catwhisker.org> <CAPyFy2AfGFQJJpjKkhkUzbXPyDbPQnDuYp-H7ko3aDRcHh1sFA@mail.gmail.com> <20201004180342.GB1349@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2020-10-04 at 11:03:42 -0700, David Wolfskill wrote: > On Sun, Oct 04, 2020 at 01:49:03PM -0400, Ed Maste wrote: > > ... > > Indeed. Let me reiterate though that this is a consequence of > > fine-tuning the conversion process; once the migration is complete it > > should not happen again. > > 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. Yes, it downloads a lot (about 1GiB), but that is due to the hashes changing. Now what happens is that you cannot just `pull` that in, due to not really having a shared ancestor (or rather, it is way too far behind). 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. % git fetch --force --all ... aaahh, that finally gets me all the refs into a proper mirror bare 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 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. 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. 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. > > Deleting and cloning again from scratch is a reasonable way to > > interact with the repository during this stage. > > > > > That is not waht I'm trying to do. I am trying to have a (separate) > > > working copy (for each branch I use) that persists from day to day, and > > > which I update from the repo shortly before I rebuild FreeBSD. > > > > 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. > 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) - in your workspace: git reset --hard stable/12 This is not expected to make sense Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201005150312.GQ92039>