From 020c1e77489b772f854bb3288b9c8d2818a6bf9d Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Fri, 18 Apr 2025 02:17:12 -0300 Subject: git mv src/content/* src/content/en/ --- .../tils/2020/11/12/git-bisect-automation.adoc | 25 ---------------------- 1 file changed, 25 deletions(-) delete mode 100644 src/content/tils/2020/11/12/git-bisect-automation.adoc (limited to 'src/content/tils/2020/11/12/git-bisect-automation.adoc') diff --git a/src/content/tils/2020/11/12/git-bisect-automation.adoc b/src/content/tils/2020/11/12/git-bisect-automation.adoc deleted file mode 100644 index dff8737..0000000 --- a/src/content/tils/2020/11/12/git-bisect-automation.adoc +++ /dev/null @@ -1,25 +0,0 @@ -= Git bisect automation -:categories: git -:sort: 1 - -It is good to have an standardized way to run builds and tests on the repository -of a project, so that you can find when a bug was introduced by using -`git bisect run`. - -I've already been in the situation when a bug was introduced and I didn't know -how it even was occurring, and running Git bisect over hundreds of commits to -pinpoint the failing commit was very empowering: - -[source,sh] ----- -$ GOOD_COMMIT_SHA=e1fd0a817d192c5a5df72dd7422e36558fa78e46 -$ git bisect start HEAD $GOOD_COMMIT_SHA -$ git bisect run sn -c './build.sh && ./run-failing-case.sh' ----- - -Git will than do a binary search between the commits, and run the commands you -provide it with to find the failing commit. - -Instead of being afraid of doing a bisect, you should instead leverage it, and -make Git help you dig through the history of the repository to find the bad -code. -- cgit v1.2.3