|
|
|
|
|
|
by saidajigumi
4133 days ago
|
|
|
Your data loss example [3] is precisely not data loss, like virtually every other example I've seen regarding git. The commits and history were definitively not lost, and although the article doesn't say, the repositories affected by this tool should have even still contained the history record of the old head(s), making rollback to the latest commits a fairly straightforward affair. This is honestly no different than someone misconfiguring a tool for any other VCS and overwriting the repo's head with old junk. In the (other VCS) case, the fix operation is to go into VCS history and resurrect the correct head commits (e.g. via a 'revert' style operation). In git's case, the fix operation is ... go into VCS history and resurrect the correct head(s), traditional revert not being relevant to how git functions in such exceptional cases. It's either ignorance or disingenuousness to call git's behavior here, though different than SVN, hg, etc. as "data loss". |
|
|
More generally, yes, the case you are worried about is typically not when there are lots of repository clones in circulation (though the KDE case [1] shows that data loss is quite possible even then and that replication is no real alternative for proper backups [2]).
And, of course, the reflog will keep commits alive for a while and garbage collection will not occur while the grace period is over.
The situation where this doesn't work so well is personal/small group repositories or branches that only experience intermittent commits and that aren't being mirrored by a large number of users. In that case, user errors can easily translate into data loss when garbage collection finally catches up with you.
[1] http://jefferai.org/2013/03/29/distillation/
[2] A practical example would be where a repository is so large that many contributors prefer to use shallow clones.