On Tue, 14 Jan 2020 at 14:28, Martin Jambor <mjam...@suse.cz> wrote: > > Hi, > > On Tue, Jan 14 2020, Andreas Schwab wrote: > > On Jan 14 2020, Georg-Johann Lay wrote: > > > >> git clone --reference original-gcc ... > > > > Don't use --reference. It is too easy to lose work if you don't know > > what you are doing. > > What are the risks, assuming I won't delete the referenced repo which > sits on the same partition of the same local disk as the new one?
If I understand correctly (and I don't use --reference so I might be wrong), with --reference you need to do a git fetch in each separate repo when you want to upate, because although they share objects they each have their own "view" of the remotes. If you do a git pull in a clone created with --reference it will fetch new objects and store them locally, it won't update the referenced repo. This means they can diverge over time and aren't sharing as much as possible (I assume that can be resolved by repack or gc? I don't know). Also, anything committed to any worktree is instantly visible to the others. I have worktrees for master, gcc-9 and gcc-8. After I backport something to gcc-9 (but before I push it upstream) I can go to the gcc-8 worktree and do 'git cherry-pick gcc-9' to apply the newest commit from gcc-9 branch to the gcc-8 branch. There's no need to push or pull anything between the worktrees, because they are all using the same clone with the same local branches. > I prefer it to worktree because I often just do have master checked out > in multiple directories and worktree would be unhappy about that... Sounds like a good use for branches :-) > and > the risk of accidentally deleting the base worktree are IMHO the same as > the risk of deleting the referenced repo. For me, there is zero chance that I'll ever think ~/src/gcc/gcc is an old tree I don't use. It's also the one where I do work on 'master' (or branches created from 'master') so I'm unlikely to ever think that's an unwanted throwaway tree that I don't need. With worktrees you'll only have 'master' checked out in one of your trees, so it doesn't take a lot of discipline to know which one is the one containing all the .git/objects and other repository metadata. > Anything that I am missing? (In other words, do I know what I am doing? :-)
