Hey Junio, On March 22, 2024 11:31:29 p.m. GMT+01:00, Junio C Hamano <gitster@xxxxxxxxx> wrote: >Olliver Schinagl <oliver@xxxxxxxxxxx> writes: > >> In some cases, we know a commit will always break bisect. This is bad >> and evil but sometimes needed. >> ... >> git commit -m 'copy old to new' -m 'GIT_SKIP_BISECT' >> ... > >If "I want a bisect to skip any commit that has 'Skip Me' in its >subject" is the case, perhaps your "git bisect run" script can say > > #!/bin/sh > > case "$(git show -s --oneline)" in > *"Skip Me"*) exit 125 ;; > esac > > ... your test script body comes here ... > if test successful > then > exit 0 > else > exit 1 > fi > This is a nice way to wrap got bisect, but from a UX point of view, having native support from the got client would be much nicer. E.g. the user doesn't have to learn about special scripts. I'd argue, if we can do it the same way everywhere (I.e. shipping such a script as part of the got distro), why not handle it nativily. The magic word could be a default with an override in the gitconfig. >The _clue_ to mark a commit to be skipped does not have to be >hardcoded commit title. It often is discovered that a commit >breaks bisection after the fact and it is not feasible to rebase >all the history after the commit. Maybe an approach more suitable >in such a situation would attach a note to such untestable commits >after the fact, and check if such a note is attached at the >beginning of "git bisect run" script and exit with 125. > >And a new "git bisect --skip-when <condition>" option can be added to >manual bisection process. The <condition> part would contain >something like > > case "$(git show -s --oneline)" in > *"Skip Me"*) exit 125 ;; > esac > >taken from the above illustration. > I've read the notes solution from 13 years ago ;) and I do like the elegance. But I think there's two cases. One during the fact, when you know this will be an issue andere in deed ons after the fact. I'll admit, I was oblivious by git notes, and will read up on it now. Always using a note for this feature does make sense, as its part of the repository. >But I am not sure what end result you are trying to achieve, so the >above are random collection of ideas. Turning them into a patch is >left as an exercise to readers. In the end, is it (internally) even possible for got bisect to check this, and would a patch that handles this 'behind the scenes' be accepted, without the user having to install special tooling (scripts)? Having said that, on a different note is 'git copy' feasable? E.g. git CP old new, where both files share the same history? Olliver
