"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On 2021-06-06 at 12:30:25, Junio C Hamano wrote: >> By default, the rerere machinery has been disabled since a bug in >> the machinery could screw up the end user's data at the most >> stressful time during the end user's workday (i.e. during conflict >> resolution). >> >> It however has been in wide use without causing much trouble (other >> than, obviously, replaying a broken conflict resolution that was >> recorded earlier when the user made a mismerge), and it is about >> time to enable it by default. > > Yes, I think this makes sense. I've been using it for quite a while > without problems and I'm usually quite good at breaking things, and if > we can make the user experience better, which I think rerere does, > that's definitely a good thing. I agree in principle, but new tests added by topics in flight need to get prepared for the change. There are, for example, misguided checks that insist that the standard error stream out of "git merge" must be absolutely empty, which will break when rerere machinery starts reporting that it prepared the preimage so that it can record the resolution. Not just rerere, but such a test is brittle and will break when other inner parts of the system starts reporting more (e.g. progress) to the standard error stream. I'd prefer to see these tests cleaned up in the right way (as opposed to setting rerere.enabled to false upfront, which hides these suboptimal tests) before this change to enable rerere by default lands, so it may need a sizeable preparatory work. Thanks.
