Re: on when to checksum

  The thing is, I don't "trickle" things in. That would be horribly 
  inefficient for me. So I go over the patches, make a mbox, and do them all 
  in one go. And then they need to happen _fast_. If it takes 20 minutes, I 
  go away for coffee or something, and then if something didn't apply 
  half-way through, I will have lost my "context".

  That's why I want things instant. Not because I have huge daily throughput 
  issues, but I have huge _latency_ issues. 

I'm curious about what is the value of the "batch" nature of that proces?

Presumably most patches apply cleanly and most or orthogonal (order independent). I'm sure that there are frequently interesting exceptions but am I generally right about "most" here?

So, if I understand, you review each change before stuffing it in a mailbox, then you apply all the patches in that mailbox in batch. In the majority of cases, the buffering of changes in the mailbox adds nothing.

Why isn't that more automated: when you approve a change, it could be applied at once, in the background. If conflictless, it can be committed, tested, whatever. If conflicting, *then* the change can be buffered up for you to look at. Explicit declarations from programmers or text-based computations about dependencies among the patches can help improve the queue management in more complicated cases.

In other words, a more asynchronous process might save you time *and* pay off by reserving more of your attention for areas where it's really needed.

-t