Re: worktrees vs. alternates

On Thu, May 17, 2018 at 5:31 AM, Jeff King wrote: > On Thu, May 17, 2018 at 06:13:55AM +0530, Sitaram Chamarty wrote: > >> I may have missed a few of the earlier messages, but in the last >> 20 or so in this thread, I did not see namespaces mentioned by >> anyone. (I.e., apologies

Re: worktrees vs. alternates

On Thu, May 17, 2018 at 06:13:55AM +0530, Sitaram Chamarty wrote: > I may have missed a few of the earlier messages, but in the last > 20 or so in this thread, I did not see namespaces mentioned by > anyone. (I.e., apologies if it was addressed and discarded > earlier!) > > I was under the

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 04:02:53PM -0400, Konstantin Ryabitsev wrote: > On 05/16/18 15:37, Jeff King wrote: > > Yes, that's pretty close to what we do at GitHub. Before doing any > > repacking in the mother repo, we actually do the equivalent of: > > > > git fetch --prune ../$id.git

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 02:18:20PM -0700, Stefan Beller wrote: > > > > You can also do periodic maintenance like: > > > > 1. Copy each ref in the forked repositories into the parent repository > > (e.g., giving each child that borrows from the parent its own > > hierarchy in

Re: worktrees vs. alternates

> > You can also do periodic maintenance like: > > 1. Copy each ref in the forked repositories into the parent repository > (e.g., giving each child that borrows from the parent its own > hierarchy in refs/remotes//*). Can you just copy? I assume the mother repo doesn't know about all

Re: worktrees vs. alternates

On Wednesday, May 16, 2018 01:06:59 PM Jeff King wrote: > On Wed, May 16, 2018 at 01:40:56PM -0600, Martin Fick wrote: > > > In theory the fetch means that it's safe to actually > > > prune in the mother repo, but in practice there are > > > still races. They don't come up often, but if you > > >

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 04:02:53PM -0400, Konstantin Ryabitsev wrote: > On 05/16/18 15:37, Jeff King wrote: > > Yes, that's pretty close to what we do at GitHub. Before doing any > > repacking in the mother repo, we actually do the equivalent of: > > > > git fetch --prune ../$id.git

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 01:40:56PM -0600, Martin Fick wrote: > > In theory the fetch means that it's safe to actually prune > > in the mother repo, but in practice there are still > > races. They don't come up often, but if you have enough > > repositories, they do eventually. :) > > Peff, > >

Re: worktrees vs. alternates

On 05/16/18 15:37, Jeff King wrote: > Yes, that's pretty close to what we do at GitHub. Before doing any > repacking in the mother repo, we actually do the equivalent of: > > git fetch --prune ../$id.git +refs/*:refs/remotes/$id/* > git repack -Adl > > from each child to pick up any new

Re: worktrees vs. alternates

On Wednesday, May 16, 2018 12:37:45 PM Jeff King wrote: > On Wed, May 16, 2018 at 03:29:42PM -0400, Konstantin Ryabitsev wrote: > Yes, that's pretty close to what we do at GitHub. Before > doing any repacking in the mother repo, we actually do > the equivalent of: > > git fetch --prune

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 03:29:42PM -0400, Konstantin Ryabitsev wrote: > On 05/16/18 15:23, Jeff King wrote: > > I implemented "repack -k", which keeps all objects and just rolls them > > into the new pack (along with any currently-loose unreachable objects). > > Aside from corner cases (e.g.,

Re: worktrees vs. alternates

On 05/16/18 15:23, Jeff King wrote: > I implemented "repack -k", which keeps all objects and just rolls them > into the new pack (along with any currently-loose unreachable objects). > Aside from corner cases (e.g., where somebody accidentally added a 20GB > file to an otherwise 100MB-repo and

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 03:01:13PM -0400, Konstantin Ryabitsev wrote: > On 05/16/18 14:26, Martin Fick wrote: > > If you are going to keep the unreferenced objects around > > forever, it might be better to keep them around in packed > > form? > > I'm undecided about that. On the one hand this

Re: worktrees vs. alternates

On Wednesday, May 16, 2018 03:11:47 PM Konstantin Ryabitsev wrote: > On 05/16/18 15:03, Martin Fick wrote: > >> I'm undecided about that. On the one hand this does > >> create lots of small files and inevitably causes > >> (some) performance degradation. On the other hand, I > >> don't want to

Re: worktrees vs. alternates

On Wed, May 16, 2018 at 10:58:19AM -0400, Konstantin Ryabitsev wrote: > The parent repo is not keeping track of any other repositories that may > be using it for alternates, which is why you basically: > > 1. never run auto-gc in the parent repo > 2. repack it manually using -Ad to keep loose

Re: worktrees vs. alternates

On 05/16/18 15:03, Martin Fick wrote: >> I'm undecided about that. On the one hand this does create >> lots of small files and inevitably causes (some) >> performance degradation. On the other hand, I don't want >> to keep useless objects in the pack, because that would >> also cause performance

Re: worktrees vs. alternates

On Wednesday, May 16, 2018 03:01:13 PM Konstantin Ryabitsev wrote: > On 05/16/18 14:26, Martin Fick wrote: > > If you are going to keep the unreferenced objects around > > forever, it might be better to keep them around in > > packed > > form? > > I'm undecided about that. On the one hand this

Re: worktrees vs. alternates

On 05/16/18 14:26, Martin Fick wrote: > If you are going to keep the unreferenced objects around > forever, it might be better to keep them around in packed > form? I'm undecided about that. On the one hand this does create lots of small files and inevitably causes (some) performance

Re: worktrees vs. alternates

On Wednesday, May 16, 2018 02:12:24 PM Konstantin Ryabitsev wrote: > The loose objects I'm thinking of are those that are > generated when we do "git repack -Ad" -- this takes all > unreachable objects and loosens them (see man git-repack > for more info). Normally, these would be pruned after a

Re: worktrees vs. alternates

On 05/16/18 14:02, Ævar Arnfjörð Bjarmason wrote: > > On Wed, May 16 2018, Konstantin Ryabitsev wrote: > >> Maybe git-repack can be told to only borrow parent objects if they are >> in packs. Anything not in packs should be hardlinked into the child >> repo. That's my wishful think for the day.

Re: worktrees vs. alternates

On Wed, May 16 2018, Konstantin Ryabitsev wrote: > Maybe git-repack can be told to only borrow parent objects if they are > in packs. Anything not in packs should be hardlinked into the child > repo. That's my wishful think for the day. :) Can you elaborate on how this would help? We're just

Re: worktrees vs. alternates

On Wed, May 16 2018, Konstantin Ryabitsev wrote: > 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

Re: worktrees vs. alternates

On 05/16/18 13:14, Martin Fick wrote: > On Wednesday, May 16, 2018 10:58:19 AM Konstantin Ryabitsev > wrote: >> >> 1. Find every repo mentioning the parent repository in >> their alternates 2. Repack them without the -l switch >> (which copies all the borrowed objects into those repos) >> 3. Once

Re: worktrees vs. alternates

On Wednesday, May 16, 2018 10:58:19 AM Konstantin Ryabitsev wrote: > > 1. Find every repo mentioning the parent repository in > their alternates 2. Repack them without the -l switch > (which copies all the borrowed objects into those repos) > 3. Once all child repos have been repacked this way,

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

On Wed, May 16 2018, Konstantin Ryabitsev wrote: > On 05/16/18 09:02, Derrick Stolee wrote: >> 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

Re: worktrees vs. alternates

On 05/16/18 09:02, Derrick Stolee wrote: > 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

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

On Wed, May 16 2018, Lars Schneider wrote: >> On 16 May 2018, at 11:29, Æ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

Re: worktrees vs. alternates

> On 16 May 2018, at 11:29, Æ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

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

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

worktrees vs. alternates

Hi, 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