On Wed, Jun 30 2021, Felipe Contreras wrote: > Ævar Arnfjörð Bjarmason wrote: >> On Mon, Jun 28 2021, Junio C Hamano wrote: > >> > I do not see a point in complicating the build procedure to avoid >> > using it. >> >> I'd really understand your and Jeff's concerns if I was proposing some >> really complex workaround, but it's just extending & making consistent >> the "mv" dance we already use for 1/2 our rules already. > > I'm not entirely sure what's going on here. We have agreed that > .DELETE_ON_ERROR and the "mv" dance are orthogonal. So the patch to use > .DELETE_ON_ERROR can move forward, while the "mv" dance can be discussed > later. > > Like Junio and Jeff, I don't see much value in the "mv" dance, but that > doesn't mean I want it gone. On the contrary, I would to try a scenario > in which it's usefull. > > But that is *orthogonal*. Leave that for another discussion. Yes, this whole sub-thread is just a side-discussion about a change-not-in-this-series, which started out as a reference to a larger series I carved this more narrow change from. >> 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 don't know about Junio, I do want to make git easier to hack for > people that don't share my setup, but I would like to know what that > setup is. I think all of this is covered in detail upthread. >> I'd think that making those rules consistent across the board makes >> things less complex, not more. > > I don't agree with that. Consistency is just one of the many factors we > have to consider. Even if 90% of instances in the documentation said > "fast forward", that doesn't necessarily mean we should convert the > remaining 10% away from "fast-foward". > > First we need to decide what is the end-goal we want to reach, and then > we can go for consistency. > > But again, this is orthogonal to this patch, isn't it? *nod*. I think for build rules it's easier to reason about them if all of them e.g. do "$(RM) $@" at the start followed by "mv $@ $@+" at the end, than wondering if the differences are accidental or intentional (in most cases they're just a historical accident).q >> Anyway, let's not discussed this forever. We're clearly getting >> nowhere. Just for the record I'm quite miffed about the bar for "I don't >> care about this area/platform/use-case, but this person actively sending >> me patches in the area says it's helpful to send more patches" is so >> low. > > I don't think it's quite like that. Skepticism doesn't mean disapproval. > > I for one are skeptic of the possitive value of the "mv" dance, but I > wouldn't be surprised in the least if you showed the value in 4 lines of > code. I just haven't seen them yet. > > Once again... That's orthogonal to this patch. *Nod*, as noted covered upthread. >> Maybe that's all worth it, and I'd be willing to take the Windows devs >> at their word that dealing with the make dependency was really *that* >> painful. But compare that to carrying a few lines of "mv $@+ $@" to, I >> daresay, make the same or larger relative improvement on AIX. > > Oh I don't trust them at all. I did maintain some Windows installers for > years, and with a couple of tricks I had no problem building them with > plain Makefiles, with much more complex dependencies. > > I'm fairly certain I could make git build for Windows with plain > Makefiles... But one controversy at a time. Yeah, I think (from memory of reading the relevant threads) it's some combinatin of "the dependency is large & painful" and "it's a bit slower". I've found it hard in the past to get accurate estimates of what's "slow" from our resident Windows maintainer:) Per: https://lore.kernel.org/git/875z1lz6wl.fsf@xxxxxxxxxxxxxxxxxxx/
