Junio C Hamano wrote:
Some ideas:
- Make clone --reference without -s not to borrow from the
reference repository. (...)
Generalize: Introduce volatile alternate object stores. Commands like
(remote) fetch, repack, gc will copy desired objects they see there.
That allows
Oswald Buddenhagen wrote:
(...)so the second approach is the bare aggregator repo which adds
all other repos as remotes, and the other repos link back via
alternates. problems:
- to actually share objects, one always needs to push to the aggregator
Run a cron job which frequently does that?
Can I use a shallow Git repo for file versioning, and regularly purge
history older than e.g. 2 weeks? Purged data MUST NOT be recoverable.
Or is there a backup tool based on shallow Git cloning which does this?
Push/pull to another shallow repo would be nice but is not required.
The files are
On 12. april 2018 23:07, Rafael Ascensao wrote:
Would initiating a repo with a empty root commit, tag it with 'base' then
use $ git rebase --onto base master@{30 days ago} master;
be viable?
No... my question was confused from the beginning. With such large files
I _shouldn't_ have history
On 12. april 2018 20:47, Ævar Arnfjörð Bjarmason wrote:
1. Create a backup.git repo
2. Each time you make a backup, checkout a new orphan branch, see "git
checkout --orphan"
3. You copy the files over, commit them, "git log" at this point shows
one commit no matter if you've done this
5 matches
Mail list logo
