On Thu, Dec 14, 2023 at 03:39:17AM -0500, Eric Sunshine wrote: > On Thu, Dec 14, 2023 at 3:13 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Wed, Dec 13, 2023 at 10:33:00PM -0500, Eric Sunshine wrote: > > > On Wed, Dec 13, 2023 at 10:11 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Mostly because your "differences in features supported by just-built > > > > one and what happens to be on $PATH can cause problems" cuts both > > > > ways [...] > > > > > > I sent an alternative solution[1] which should sidestep this objection. > > > > Thanks, I've replied to the thread. I think by now there are three > > different ideas: > > > > - Improve the logic to pick some kind of diff implementation, which is > > my patch series. It would need to be improved so that we also probe > > whether the respective Git executables actually understand the repo > > format so that we can fall back from the just-built Git to system's > > Git. > > > > - Munge the whitespace of the expected results with some regexes. > > I like that idea better because we can avoid the git-diff(1) > > problem, but find that the result is somewhat hard to read. > > > > - Fix the ".expect" files so that we can avoid all of these games. > > > > I actually like the last option most. I'll have a go at it and send this > > third version out in a bit. > > I sent a reply[1] in the other thread explaining why I'm still leaning > toward `sed` to smooth over these minor differences rather than > churning the "expect" files, especially since the minor differences > are not significant to what is actually being tested. That said, I > won't stand in the way of such a patch to "fix" the "expect" files, > but it feels unnecessary. > > [1]: https://lore.kernel.org/git/CAPig+cSkuRfkR2D3JqYcbaJqj485nfD9Nq6pM=vXWB5DJenWpA@xxxxxxxxxxxxxx/ Yeah, our mails indeed crossed. I personally do not mind much which of our patches land upstream and would be happy with either. Thanks! Patrick
Attachment:
signature.asc
Description: PGP signature
