Re: worktrees vs. alternates

From: Lars Schneider <larsxschneider@gmail.com>
Date: May 16, 2018, 09:51 UTC
Message-ID: <81B00B00-00F4-487A-9D3E-6B7514098B29@gmail.com>
In-Reply-To: <87po1waqyc.fsf@evledraar.gmail.com>

Show 28 quoted lines

> On 16 May 2018, at 11:29, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> 
> 
> On Wed, May 16 2018, Lars Schneider wrote:
> 
>> I am looking into different options to cache Git repositories on build
>> machines. The two most promising ways seem to be git-worktree [1] and
>> git-alternates [2].
>> 
>> I wonder if you see an advantage of one over the other?
>> 
>> My impression is that git-worktree supersedes git-alternates. Would
>> that be a fair statement? If yes, would it makes sense to deprecate
>> alternates for simplification?
>> 
>> [1] https://git-scm.com/docs/git-worktree
>> [2] https://git-scm.com/docs/gitrepository-layout#gitrepository-layout-objectsinfoalternates
> 
> It's not correct that worktrees supersede alternates, or the other way
> around, they're orthagonal features.
> 
> git-worktree allows you to create a new working directory connected to
> the same local object store.
> 
> Alternates allow you to declare in any given local object store, that
> your set of objects isn't complete, and you can find the rest at some
> other location, those object stores may or may not have more than one
> worktree connected to them.

OK. I just wonder in what situation I would work with an incomplete object store. The only use case I could imagine is that two repos share a common set of objects (most likely blobs). However, in that situation I would keep the two independent lines of development in a single repo with two root commits.

Would it be fair to say that "git alternates" are a good mechanism to cache objects across different repos? However, I would consider a cache hit between different repos unlikely. In that line of thinking "git worktree" would be a good (maybe better?) mechanism to cache objects for a single repo?

Thanks, Lars