Junio C Hamano wrote:
>     I have "largedir" I want to get rid of, but there is a directory
>     I want to save, "largedir/precious", in it, so I do
>         cp -R largedir/precious precious
>     and then run 'rm -rf largedir' in another terminal in parallel.

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".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to