Skip site navigation (1)Skip section navigation (2)
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>