Re: worktrees vs. alternates

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 16, 2018, 17:54 UTC
Message-ID: <87in7nbi5b.fsf@evledraar.gmail.com>
In-Reply-To: <20180516154935.GA9712@chatter>

On Wed, May 16 2018, Konstantin Ryabitsev wrote:

Show 13 quoted lines

> On Wed, May 16, 2018 at 05:34:34PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>I may have missed some edge case, but I believe this entire workaround
>>isn't needed if you guarantee that the parent repo doesn't contain any
>>objects that will get un-referenced.
>
> You can't guarantee that, because the parent repo can have its history
> rewritten either via a forced push, or via a rebase. Obviously, this
> won't happen in something like torvalds/linux.git, which is why it's
> pretty safe to alternate off of that repo for us, but codeaurora.org
> repos aren't always strictly-ff (e.g. because they may rebase themselves
> based on what is in upstream AOSP repos) -- so objects in them may
> become unreferenced and pruned away, corrupting any repos using them for
> alternates.

Right, it wouldn't work in the general case. I was thinking of the use-case for doing this (say with known big monorepos) where you know a given branch won't be unwound.

Still, there's a tiny variation on this that should work with arbitrary repos whose master may be rewound, you just setup a refspec to fetch their upstream HEAD into master-1 without having "+" in the refspec. Then if they never rewind you keep fetching to master-1 forever.

If they do rewind you fetch that to master-2 and so forth, so you can follow an upstream rewinding branch while still guaranteeing that no objects ever disappear from your parent repo. This is still a lot simpler than the juggling approach you noted, since it's just a tiny shellscript around the "fetch".

This assumes that:

  1. Whenever this happens the history is still similar enough that the
     parent won't balloon in size like this, or at least it won't be
     worse than not using alternates at all.

 2. You're getting most of the gains of the object sharing by just
    grabbing the upstream HEAD branch, i.e. you don't have some repo
    with huge and N unrelated histories.