`git bisect run` with a bash function

Question

Is there a convenient way to write a bash script to run git bisect run, where the bisect command used is itself a bash function? If my function is named step, it appears that git bisect run step and git bisect run bash -c step are both unable to see the function.

My script currently looks something like

function step {
  # Do a bunch of steps here
}

if [[ $_ == $0 ]]  # Test if the script is being sourced
then
  git bisect start
  git bisect bad bad-commit
  git bisect good good-commit
  git bisect run bash -c ". $0 && step"
  git bisect log
fi

This uses a gross hack of making the script source itself in the command passed to git bisect run, and which means I have to check if the script is currently being sourced before attempting to execute the git bisect commands.

I suppose I could just split the bash function into a seperate script, buts there a better way to do this all in one file?

You can [export a function to the environment](https://unix.stackexchange.com/questions/22796/can-i-export-functions-in-bash)…although I would just move the contents of your `step` function into a separate script. — larsks, Mar 16 '21 at 22:43

score 1 · Accepted Answer · answered Nov 18 '21 at 21:27

1

You can either export the function with export -f step or you can use set -a to export everything in your script.

answered Nov 18 '21 at 21:27

unDeadHerbs

1,306
1
11
19

That is what I ended up doing, I think. Thanks! – l k Nov 21 '21 at 00:07

score 0 · Answer 2 · answered Dec 14 '22 at 13:35

Is there a convenient way to write a bash script to run git bisect run, where the bisect command used is itself a bash function?

You will be able to re-test your script with Git 2.40 (Q1 2023) since git bisect^(man) becomes a builtin.

No more bash script.

See commit 0da4b53, commit 252060b, commit 8962f8f, commit 461fec4, commit f37d0bd (10 Nov 2022) by Đoàn Trần Công Danh (sgn).
See commit 2445d34 (11 Nov 2022) by Taylor Blau (ttaylorr).
See commit 049141d (15 Nov 2022), and commit 5512376, commit 929bf9d, commit bdd2aa8, commit 982fecf (10 Nov 2022) by Ævar Arnfjörð Bjarmason (avar).
See commit 73fce29, commit df63421 (10 Nov 2022) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit bee6e7a, 14 Dec 2022)}

For instance:

bisect--helper: emit usage for "git bisect"

^{Signed-off-by: Ævar Arnfjörð Bjarmason}
^{Signed-off-by: Đoàn Trần Công Danh}
^{Signed-off-by: Taylor Blau}

In subsequent commits we'll be removing "git-bisect.sh" in favor of promoting "bisect--helper" to a "bisect" built-in.

In doing that we'll first need to have it support git bisect--helper <cmd> rather than git bisect--helper --<cmd>, and then finally have its "-h" output claim to be "bisect" rather than "bisect--helper".

Instead of suffering that churn let's start claiming to be "git bisect"^(man) now.
In just a few commits this will be true, and in the meantime emitting the "wrong" usage information from the helper is a small price to pay to avoid the churn.

Let's also declare "BUILTIN_*" macros, when we eventually migrate the sub-commands themselves to parse_options() we'll be able to re-use the strings.
See 0afd556 ("worktree: define subcommand -h in terms of command -h", 2022-10-13, Git v2.39.0-rc0 -- merge listed in batch #8) for a recent example.

`git bisect run` with a bash function

2 Answers2

`bisect--helper`: emit usage for "git bisect"

`git bisect run` with a bash function

2 Answers2

bisect--helper: emit usage for "git bisect"

`bisect--helper`: emit usage for "git bisect"