Am 14.01.22 um 09:04 schrieb Ramkumar Ramachandra: > René Scharfe wrote: >> Using the shell allows the bisect run command to be any shell command, >> not just some script. E.g. you could bisect a build failure with just >> "git bisect run make". Quite useful. > > Ah, that's quite useful, yes. The problem of improving user > experience with bisect is getting more and more hairy. May I suggest > something tractable, albeit not too elegant, and certainly not > perfect, in view of improving user experience in common use cases? I like the pragmatism. > 1. If argv[0] of the supplied command is found in $PATH, check it for > executable permissions. Otherwise, error out. It's highly unlikely > that the user meant a shell builtin, which would supersede the > executable in $PATH. Installing something in $PATH and forgetting to make it executable sounds like a very rare case. And if we find such a thing, would it warrant erroring out? What if there is an executable version somewhere else in the $PATH or a shell builtin or an alias? > 2. If argv[0] is found in the current directory, prompt for "Did you > mean ... [Y/n]?" That is more likely, I imagine, but is the existence of such a file strong enough a signal to interrupt the program? I think we are better off making sure there actually is a problem first. > 3. If checking on merge-base fails, improve the error message with > "Perhaps your bisect script is broken?" and reset bisect > automatically. That would have no effect if the bad commit is a straight descendant of the good one. And a merge base being bad can have other causes than a missing script. René
