How much is Hg/Git repository corruption an issue?

Environment: 14 or so engineers/physicists/mathematicians (read: none really interested in spending their time on things like repo maintance and similar things)

They will be using it, in terms of software engineering nowadays, for rather small projects, but one can expect that a lot of non-code stuff will also wind up in there (data files, some images, some PDF and word documents … nothing large in size but it will wind up in there along with the source files).

  • Am I doing it wrong? Merging SVN changes from trunk into a git branch. Using merge --squash
  • Git Push Heroku Master results in Fatal Error When Trying to Deploy App
  • Trouble opening repository with NodeGit
  • Tell gitk to ignore all branches that match pattern
  • Should I remove merged branches?
  • How to see code changes after git pull?
  • How much is repository corruption in such environment an issue when using either Hg or Git?

    Platform: Windows and Mac’s (mostly Windows)

  • Saving changes in a remote branch in Git
  • Hide listing of certain files/directories after git pull?
  • showing commits not yet cherry-picked from a range of commits
  • Git notes perfomance and alternatives
  • How to commit a git repository inside another git repository
  • Jenkins - GitHub Enterprise API, HTTP Code -1
  • 3 Solutions collect form web for “How much is Hg/Git repository corruption an issue?”

    Personally (using Mercurial) I never experienced a technically corrupted repository. Actually I’d say the chance to corrupt a repository is very very low when using the regular commands only (add/remove files, commit, push, pull, merge).

    Things might get more complicated when you start playing around with history, e.g. permanently delete changesets, rebase branches, collapse changesets — these action inherently are destructive. However, while you can act destructively in Mercurial, you’ll have to enable the corresponding commands explicitly and often get meaningful warnings prior execution of potentially problematic commands.

    AFAIK Git has less barriers in corrupting a repository because it supports more destructive action by default (Git users, correct me if I’m wrong).

    Finally you shouldn’t care that much: One big advantage of DVCS is that each clone is an independent complete repository. If a repo is corrupted, only one or a few developers are affected by this problem. If the problem cannot be fixed, reclone from the central or a colleague’s repo and continue working on that state.

    If by corruption you mean erroneous manipulation that will lead to a strange state of the repository, there sure will be some at the beginning when your coworkers will learn to use the new tool.

    But Git and Mercurial both offer some tools to mend broken repositories. As long as your team is disciplined, I think it’s safe to say that there will be no corruption problem that can’t be corrected.

    I advice you to choose at least one person as administrator and then take your time to think about the structure you want to give to your repositories.

    I wouldn’t worry about on-disk corruption. Sure, having everything tightly packed makes a bit flip more dangerous, but since everything is cloned everywhere else you’re unlikely to lose data.

    Git Baby is a git and github fan, let's start git clone.