Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

Junio C Hamano wrote:

I would argue that there is something to "fix", but that fix involves making the cp a purely atomic operation which is super-complicated, and totally not worth it. Would you _not_ like the above example to work? Then how can you say that there's nothing to be fixed?

Consider a slightly different example: I rename a file while having an
active file handle open in a process that's reading the file.  Will
the rename fail or will the fread() in the process fail?  Nope, both
work fine.  Replace "rename" with "remove", and we still have the same
answer.  Ofcourse there are no guarantees: I can start up another
process to overwrite the sectors corresponding to that file's data
with zeros; unless the complete file is there in the kernel buffer, a
read() will eventually end up slurping in the zeros (or fail?), right?
 It's just that it works in practice.

Yet another example: I have a terminal pointing to a directory, and I remove that directory in another terminal. When I switch back to the original terminal, I can't cd .., because getcwd() fails. This has annoyed me endlessly in practice, and I would really like to fix this if I can.

Don't accept the way things are, and assume that there's nothing to be "fixed". In my opinion, if something about a piece of software annoys you, there is always something to fix. It just depends on what _can_ be fixed in a reasonable amount of time with a good engineering solution. There's no need to go to the other extreme: I'm not interested in rewriting the whole operating system in Haskell and providing theoretical guarantees for everything.

Coming back to our push example, I don't see why you think HEAD is special: I could even say git push master and expect it to race with an update-ref. But nobody is complaining about that: if someone does complain, I would seriously consider copying master to PUSH_HEAD early (and push that). With HEAD, however, someone is complaining (namely, me): pushing usually means that I've finished working on that branch, and want to switch to another branch and continue working. Why should I have to wait for the push to complete? I've hit this bug several times (from terminal as well as Magit), and this patch fixes the problem for me in practice.

That said, I agree that my patch does not guarantee anything (and I will modify my commit message to clarify this). I'm just expressing my opinion on the issue of "fixing problems".