Junio C Hamano <gitster@xxxxxxxxx> writes: >> However, in doing so we've been fooling ourselves when it comes to >> what trace2 events we log. The events tested for in >> 0a9dde4a04c (usage: trace2 BUG() invocations, 2021-02-05) are not the >> real ones, but those that we emit only from the "test-tool". > > I can fully agree with the above reasoning, i.e. let's test what we > do use in production, instead of something nobody uses for real, if > we were adding a test for BUG() in vacuum, but why did we have to > "fake" it in the first place? > ... > Are we sure that the reason no longer applies? How do we know? We > would want to explain that to future developers in the proposed log > message, I would think. We can flip it the other way around. I do not think I ever saw anybody asked anybody on this list who got a BUG() message to use the coredump to do something useful. Don't modern distros ship with "ulimit -c 0" these days? It might be possible that a better direction is to introduce GIT_ABORT_ON_BUG environment or core.abortOnBUG configuration that chooses between abort() and exit(99), or something like that, and then we switch to use the latter by default over time?
