> On 16 May 2018, at 11:29, Ævar Arnfjörð Bjarmason <ava...@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
