3 ms·

Why not just use tar or any other archive tool on the repository .git folder? Unless your repository is a un-gc'd mess with millions of unpacked objects...

• deleted 3y ago
  [deleted]
• pbhn 3y ago
  I think that is a fair alternative, but restoring the backup means that the repository is in a bit of a weird state. Whereas a bundle can be cloned from nicely. Your way does have the property that it includes hooks and config, though (which could be desired or not).
  • Ferret7446 3y ago
    There are very few/no operations that will put a git repository in a "weird" state. Actually, any snapshot of a Git repository is consistent (due to its CAS nature), minus the index which doesn't really need backup anyway.
• wkennington 3y ago
  This is also non-deterministic between versions of tar, but I guess for this usecase that would be fine. It’s just not good for reproducible build systems when trying to recreate tarballs after years.
• everybodyknows 3y ago
  Does not meet stated goal of the author: > The naive solution of simply backing up the entire file-system tree is clearly not desirable since that would clutter the backup with useless build artifacts. Build artifacts can be filtered out with tar --exclude patterns, but this is a language-dependent set that will require curation.
  • cesarb 3y ago
    Wouldn't all these useless build artifacts be outside the .git folders?