Re: worktrees vs. alternates

From: Derrick Stolee <stolee@gmail.com>
Date: May 16, 2018, 13:02 UTC
Message-ID: <fc2f1fdf-222f-aaee-9d58-aae8692920f5@gmail.com>
In-Reply-To: <87muwzc2kv.fsf@evledraar.gmail.com>

On 5/16/2018 6:33 AM, Ævar Arnfjörð Bjarmason wrote: [big snip]

>
> And here's where this isn't at all like "worktree", each of those 100
> will have their own "master" branch, and they can all create 100
> different branches called "topic" that can be different.

This is the biggest difference. You cannot have the same ref checked out in multiple worktrees, as they both may edit that ref. The alternates allow you to share data in a "read only" fashion. If you have one repo that is the "base" repo that manages that objects dir, then that is probably a good way to reduce the duplication. I'm not familiar with what happens when a "child" repo does 'git gc' or 'git repack', will it delete the local objects that is sees exist in the alternate?

GVFS uses alternates in this same way: we create a drive-wide "shared object cache" that GVFS manages. We put our prefetch packs filled with commits and trees in there, and any loose objects that are downloaded via the object virtualization are placed as loose objects in the alternate. We also store the multi-pack-index and commit-graph in that alternate. This means that the only objects in each src dir are those created by the developer doing their normal work.

Thanks, -Stolee