Re: reducing prune sync()s

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 29 May 2008, Linus Torvalds wrote:
> 
> So if you have a system crash at a really bad time, you may have a git 
> repository that needs manual intervention to actually be *usable*. I hope 
> nobody ever believed anything else. That manual intervention may be things 
> like:
> ...
>  - actually throw away broken commits, and re-create them (ie basically 
>    doing a "git reset <known-good-state>" plus re-committing the working 
>    tree or perhaps re-doing a whole "git am" series or something)

The important part here is that it's only the *new* state that can be this 
kind of "broken commits". In other words, you'd never have to re-do actual 
*old* commits, just the commits you were doing as things crashed - the 
commits that you were in the middle of doing, and still have the data for.

Example from my case: I may have series of 250+ commits that I create with 
"git am" when I sync up with Andrew, and I very much want the speed of 
being able to create all that new commit data without ever even causing a 
_single_ synchronous disk write.

So if the machine were to crash in the middle of the series, I might lose 
all of that data, but I still have my mailbox, so I'd just need to reset 
to the point before I even started the "git am", and re-do the whole 
series. My actual *base* repository objects would never get corrupted.

[ And one final notice: I don't know about others, but I've actually had 
  more corruption from disks going bad etc that from system crashes per 
  se. And when *that* happens, old data is obviously as easily gone as new 
  data is. So absolutely _nothing_ replaces backups. It doesn't matter if 
  you do a "fsync()" after every single byte write - a disk crash can and 
  will corrupt things that were "stable". So even "stable storage" is 
  very much unstable in the end. ]

			Linus