On Fri, Apr 6, 2012 at 08:44, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On Fri, Apr 6, 2012 at 10:24 PM, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: >> But even so: do we make any promises that (say) git-add is atomic in the >> sense that a reader always gets the before-update results or the >> after-update results? Non-builtins (e.g. git add -p) may make small >> incremental updates to the index, so they wouldn't be atomic anyway. > > Take git-checkout. I'm ok with it writing to worktree all old entries, > or all new ones, but please not a mix. Why, what is the big deal? git-checkout has already written the file to the local working tree. Its now just reflecting the updated stat information in the index. If it does that after each file was touched, and it aborts, you still have a partially updated working tree and the index will show some updated files as stat clean, but staged relative to HEAD. I don't think that is any better or worse than the current situation where the working tree is shown as locally dirty but the index has no staged files. Either way you have an aborted checkout to recover from by retrying, or git reset --hard HEAD. In the retry case, checkout actually has less to do because the files it already cleanly updated match where its going, and thus it doesn't have to touch them again. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html