Re: How de-duplicate similar repositories with alternates
- Date: Thu, 29 Nov 2018 21:43:15 +0100
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: How de-duplicate similar repositories with alternates
On Thu, Nov 29, 2018 at 9:15 PM Ævar Arnfjörð Bjarmason
> On Thu, Nov 29 2018, Stefan Beller wrote:
> > On Thu, Nov 29, 2018 at 7:00 AM Ævar Arnfjörð Bjarmason
> > <avarab@xxxxxxxxx> wrote:
> >> A co-worker asked me today how space could be saved when you have
> >> multiple checkouts of the same repository (at different revs) on the
> >> same machine. I said since these won't block-level de-duplicate well
> >> one way to do this is with alternates.
> > Another way is to use git-worktree, which would solve the gc issues
> > mentioned below?
> > I view alternates as a historic artefact as the deduping
> > of objects client side can be done using worktrees, and on the
> > serverside - I think - most of the git hosters use namespaces
> > and put a fork network into the same repository and use pack islands.
> > Can you elaborate on why worktrees would not solve the problem?
> > (I initially was hesitant to use them as I liked going into .git and tempering
> > with files such as the config directly. But now I cannot `cd .git` any more;
> > it turns out the advantages outweigh this corner case that I was attached to)
> This was discussed recently on-list & I chimed in with details about
> that here:
> https://public-inbox.org/git/87po1waqyc.fsf@xxxxxxxxxxxxxxxxxxx/ &
> In particular the "multiple devs" use-case described in the latter
> E-Mail is what I have in mind. Worktrees are inherently unsuitable for
Yeah, the separate ref namespace is something I would like to have on
the client side too. I did consider implementing it a couple times but
it's really no small task. Naively, I could achieve that pretty quick
if all refs are loose, but performance would tank once the number of
refs goes over say a hundred.