Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Even if you don't care about the end result or making git easier to hack > on for people who don't share your setup, I'd think that making those > rules consistent across the board makes things less complex, not more. I think that it is where we disagree. "Remove $@+ and $@, generate into $@+ and then move it to $@" idiom has a legitimate reason to be used, and I do not want to see it blindly used where there is no reason to do so. It misleads less experienced readers. If we write a custom script that does not promise atomicity, it is a quite natural pattern to use, and it is clear to readers what is going on, especially when "generate into $@+" step is done via redirection. I despise "$(CC) -o $@+ && mv $@+ $@" because there simply shouldn't be a need to do so---unlike our custom script that sends its output to its standard output, $(CC) ought to know better. But as you said elsewhere, the patch in question is *not* about adding more use of "mv $@+ $@" in inappropriate contexts, so let's stop discussing it now. We take advantage of .DELETE_ON_ERROR that allows us to use the upfront "rm -f $@ $@+" we do in the idiom, which is a good thing.
