4 ms·

I very much doubt that this is a Git issue, but suspect that it is instead a file system/OS/hardware issue. The problem is that operating systems generally offe

I very much doubt that this is a Git issue, but suspect that it is instead a file system/OS/hardware issue. The problem is that operating systems generally offer only very limited guarantees about the atomicity of the bits actually being physically stored on a device (at least guarantees that can be used with reasonable efficiency). It should not normally be a problem, but a power failure just at the wrong time seems the prime suspect to me; there's nothing in Git's logic that should normally allow for such a problem. See, for example, the "Failure to sync" section of SQLite's page on "How to Corrupt an SQLite Database". [1] https://www.sqlite.org/howtocorrupt.html#_failure_to_sync https://www.sqlite.org/howtocorrupt.html#_failure_to_sync

dboreham 9y ago
Um..a mission critical data store shouldn't be affected by a "power failure at just the wrong time".
- rbehrends 9y ago
  Sure, but the same things could happen to (say) a relational database under the same circumstances. There's nothing that you can do if (say) the hardware lies to you about having written bits to disk or reorders writes. I was citing the SQLite page for a reason. You can only work with the tools that the OS gives you.
- flukus 9y ago
  Git is not a mission critical data store. Corruption should cause a bad day, not a disaster.
tomxor 9y ago
It is a git issue... File system atomicity is not the issue: Creating a commit is a process of creating a whole collection of blobs and trees and ultimately a commit tree object, this is fundamentally the way git works. There are many external reasons it could fail half way through creating that tree of objects (objects are files) and that has nothing to do with atomicity of those external factors. This type of incident is not irrecoverable, but it will hella-waste-your-fucking-time (FYI I really like git, but it's far from infallible)... Try it out and you will have a fun time following the trail of dangling objects. My point is not that git is fundamentally flawed (fundamentally it's extremely resilient and elegant), but merely that "commit" being a porcelain command should provide a simple way to recover from arbitrary failure without having to dive deeply into the internals and plumbing commands (it's another CLI UI failure)... I knew what was wrong but it was such a pain to reconcile that I resorted to re-cloning, imagine what a confusing mess it would appear to a regular user.

dboreham 9y ago

Um..a mission critical data store shouldn't be affected by a "power failure at just the wrong time".

rbehrends 9y ago
Sure, but the same things could happen to (say) a relational database under the same circumstances. There's nothing that you can do if (say) the hardware lies to you about having written bits to disk or reorders writes. I was citing the SQLite page for a reason. You can only work with the tools that the OS gives you.
flukus 9y ago
Git is not a mission critical data store. Corruption should cause a bad day, not a disaster.

tomxor 9y ago

It is a git issue... File system atomicity is not the issue: Creating a commit is a process of creating a whole collection of blobs and trees and ultimately a commit tree object, this is fundamentally the way git works. There are many external reasons it could fail half way through creating that tree of objects (objects are files) and that has nothing to do with atomicity of those external factors. This type of incident is not irrecoverable, but it will hella-waste-your-fucking-time (FYI I really like git, but it's far from infallible)... Try it out and you will have a fun time following the trail of dangling objects. My point is not that git is fundamentally flawed (fundamentally it's extremely resilient and elegant), but merely that "commit" being a porcelain command should provide a simple way to recover from arbitrary failure without having to dive deeply into the internals and plumbing commands (it's another CLI UI failure)... I knew what was wrong but it was such a pain to reconcile that I resorted to re-cloning, imagine what a confusing mess it would appear to a regular user.