On Wed, May 16 2018, Robert P. J. Day wrote: > On Wed, 16 May 2018, Ævar Arnfjörð Bjarmason 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. > > just to be clear here, there should be nothing about how alternates > are set up for a repository that should affect the normal behaviour of > working trees for that repository, correct? i never thought there was, > i just thought i'd make absolutely sure. That's correct. The worktree(s) are logically composed of the index/cache, checked-out files, and the local reference store (and some auxiliary things, like per-worktree refs like HEAD, and config...). Whether you have one worktree or many, eventually git needs to look up objects somewhere. The alternates mechanism is just one more way to specify where to look, along with some special logic in pack-objects and the like where we need to be aware of them for the purposes of maintaining objects in the repository.
