Re: clone, hardlinks, and file modes (and CAP_FOWNER)
- From
Andreas Krey <a.krey@gmx.de>
- Date
- Aug 24, 2018, 19:59 UTC
- Message-ID
- <20180824195905.GA19781@inner.h.apk.li>
- In-Reply-To
- <87tvnjes6y.fsf@evledraar.gmail.com>
On Fri, 24 Aug 2018 16:48:37 +0000, Ævar Arnfjörð Bjarmason wrote: ...
> I don't understand how this hardlink approach would work (doesn't mean > it won't, just that I don't get it).
I just detect whether there is insufficient sharing (df is quite handy here; 'df this/.git that/.git' tells the unshared part of that/.git only).
When I detect 'unsharedness', I just hardlink the biggest .pack and the corresponding .idx into the target repo, create a .keep file for that, run 'git gc', and remove the .keep file. Effect: repack uses the .kept file and only creates a small additional pack file for the remaining objects, thus the biggest part of the objects are now shared between the cache and the target repo.
This is going to be run once a week over all the repos on a machine (that were created by our tooling and thus have known locations), to avoid eventual repacks of repos to gradually and completely lose the sharedness of the objects/packs.
> If you have such a tightly coupled approach isn't --reference closed to > what you want in that case?
Close, but not. --reference et al. all need the promise that the referenced repo isn't going away, and I don't want to rely on this (if someone thinks he can drop the cache this should not lead to breakage in the work repos).
- Andreas
-- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800