Date: Sat, 26 Sep 2020 14:42:12 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@freebsd.org> To: David Wolfskill <david@catwhisker.org> Cc: git@freebsd.org Subject: Re: Question on (my) workflow migration svn -> git Message-ID: <20200926124212.GL92039@acme.spoerlein.net> In-Reply-To: <20200926020946.GK1390@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2020-09-25 at 19:09:46 -0700, David Wolfskill wrote: > On Fri, Sep 25, 2020 at 07:23:07PM +0200, Ulrich Spörlein wrote: > > On Thu, Sep 24, 2020 at 10:53 PM Brooks Davis <brooks@freebsd.org> wrote: > > ... > > > I don't see a good way to keep a bare repo on the laptop. > > > > > > I hope this give you an idea where to start. > > > > Why not a bare repo same as with the svnsync copies before? > > > > On each machine (doesn't matter if connected or not) he could: > > > > git clone --bare https://.../{src,ports} > > > > and "git fetch --all --prune" (or some combination) whenever internet > > connectivity exists. Then it's easy enough to clone from that local > > copy for the various branches, > > I have a local copy of the freebsd-cgit-beta from around 01 September > (that I had picked up for experimentation). > > So I tried making a bare clone of it: > > * cd <some scratch area> > * git clone --bare file:///repo/git/freebsd/freebsd-cgit-beta > > (which created freebsd-cgit-beta.git/). > > The original was ~2.5 GB; the bare clone, ~1.2 GB. Ok, this is where you went wrong, I think. Your copy of freebsd-cgit-beta is a regular clone, yes? Then all the `refs` in there are suitable for a checked out copy, but not to serve as a "master copy" of sorts. (fun fact, you can convert your existing clone into a bare repo by taking the .git content and 2-3 quick edits to the config therein, but that's more advanced and would require some more trial and error round trips) Please start from this and only this: git clone --bare https://cgit-beta.freebsd.org/src.git The worktree stuff is then as simple as this: % cd src.git % git show-ref|grep stable.12 e9c4330183dcfe8a5d26843613adc0a348fd0544 refs/heads/stable/12 % git worktree add ../stable_12 stable/12 Preparing worktree (checking out 'stable/12') Updating files: 100% (81262/81262), done. HEAD is now at e9c4330183d MFC r360483,360484: Make nvmecontrol work with nda like it does with nvd, and associated bits. % git worktree add ../current main Preparing worktree (checking out 'main') Updating files: 100% (82279/82279), done. HEAD is now at 9b8dbe73434 Revert most of r360179. % git worktree list /tmp/src.git (bare) /tmp/current 9b8dbe73434 [main] /tmp/stable_12 e9c4330183d [stable/12] For debugging, please have a look at `git show-ref` outputs of the various repos, this will tell you what refs are known to them, and if stable/12 is not there, all your later attempts to check it out were doomed to fail. Why might stable/12 not be there? For that, please check `config` in the bare repo (actually it omits any `fetch` directives, as it defaults to fetching em all), or `.git/config` in a non-bare repo, it'll tell you what it fetches from where. > For my use case, it is important to me to keep my local private > mirrors as close as possible to "the same" (as one another) except > for the defined periods during which they are being updated. Hmm, instead of rsync one into the other and potentially clobbering custom branches or pulling massive pack files over and over again, I think this can be better achieved by only checking out the youngest common commit. So instead of rsync-over-ssh, you would do the following when synching them up: % hash=`ssh otherhost "cd /path/to/checkout && git show -s --format=%H"` % git fetch --prune [in the bare repo, this runs after the above, so it's guaranteed to have that ref] [actually, I think you can also git pull in the worktree and it will adjust the bare repo accordingly] % cd /worktree && git reset --hard ${hash} Hmm, I think you must pull actually, yeah, try with pulling in your checkout instead of the fetch. % cd /worktree && git pull && git reset --hard ${hash} This will bring your worktree up the latest, but the bump it down to whatever the otherhost had checked out last. Cheers Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200926124212.GL92039>