fix: switch back from native rebase to custom for finding commits, again

actually no need to use native rebase for __finding__ the commits.
for actually rebasing, we're already doing it w/ the native rebase.

for finding commits, using the native rebase had various issues,
it involved having to do other hacks & work-arounds,
and in general didn't represent what we were actually doing,
so e.g. could cause unwanted side-effects, e.g. by calling the
post-rewrite hook, when it's not actually meant to.

Signed-off-by: Kipras Melnikovas <kipras@kipras.org>

Author: kiprasmel

git-stacked-rebase.ts

@@ -101,115 +101,6 @@ function areOptionsIncompetible(
 	return reasons.length > 0;
 }
 
-/**
- * some notes:
- *
- * 1. re: "the different ways to launch git rebase":
- *
- * 1.1 initially, we started probably the hardest way:
- *     we tried to replicate the behavior of git rebase, by:
- *
- * 1) finding which commits we need (manually by ourselves),
- * 2) letting the user edit our own git-rebase-todo file
- *    (already containing branch boundaries generated by us),
- * 3) creating & writing to files inside `.git/rebase-{merge|apply}/`,
- *    just like git rebase would, to represent the current state [1].
- * 4) and then exec'ing a `git rebase --continue`,
- *    so that the user gets launched into the rebase.
- *
- *
- * 1.2 later, we started using 2 rebases - 1st for finding the commits, 2nd for the actual rebase.
- *
- * important switch that i didn't think had significance until 1.3 --
- * using `editorScript`s (providing an env var - a string of a path to a bash script
- * that will move the user-edited & our-processed git-rebase-todo file
- * into the proper place (.git/rebase-{merge|apply}/git-rebase-todo)
- * right when the rebase starts, thus no longer having to `--continue` (!),
- * which is what broke things that were discovered
- * and fixed in 1.3 by (fabricately) introducing `--continue` back)
- *
- *
- * 1.3 but soon after, things started breaking.
- *
- * i didn't understand why.
- *
- * but after playing w/ it for a while, realized that it's stuff like `reword`
- * that breaks, as long as  we launch the rebase with an `editorScript`.
- * e.g. git would ask to identify yourself - config wouldn't be detected,
- * and our `--apply` was completely broken as well [2].
- *
- * thus we started manually adding a first command `break`
- * into the proper `git-rebase-todo` file [3]
- * so that we can launch `--continue` again,
- * after the `editorScript` had finished,
- * and that somehow fixed everything & we're back to normal.
- *
- *
- *
- * i am still not sure what the best approach is,
- * though i think i know which one's aren't.
- *
- * 1.1 seems bad because imitating the full behavior is hard,
- *
- * e.g. respecting commit.gpgSign required creating a file `gpg_sign_opt`
- * with content `-S` - there's probably a ton of stuff like this i didn't even realize
- * that git has, and it's possible more will be added in the future.
- * you can obviously see the problems that stem from this.
- *
- * 1.2 seems bad because it, apart from being broken until 1.3,
- * also used 2 rebases instead of 1, and that is kinda hacky.
- * stuff like git hooks exists, e.g. post-write,
- * that even we ourselves utilize,
- * and launching 2 rebases means producing side-effects
- * like this, and we're potentially breaking end users' workflows.
- *
- * thus, 1.3 seems like a clear winner, at least for now.
- * especially up until we investigate the break + continue thingie -
- * ideally we wouldn't need it.
- *
- *
- *
- * ---
- *
- * [1]
- * on representing the _state_ -- git rebase,
- * specifically the --interactive one (which is what we have here as well),
- * is _not_ a continuous command that goes through and is 100% done when it exits.
- *
- * there are some cases where it intentionally exits, to allow the user
- * to do further interactions, and later --continue the rebase
- * (e.g. `edit`, `break` etc.).
- *
- * thus, some state needs to be saved, so that the user, once they're done,
- * can tell git to --continue.
- *
- * turns out, git does this very simply - by saving files inside `.git/`,
- * and `.git/rebase-{merge|apply}/` folders.
- * this simple design is a big part in allowing tools like us,
- * git-stacked-rebase, to work, or rather - to expand upon the existing stuff,
- * w/o having to re-implement everything ourselves.
- *
- * [2]
- * on the --apply being broken - it's the logic of `parseNewGoodCommands` that seems broken.
- *
- * right before realizing 1.3 and writing this comment,
- * i wrote a lengthy comment there as well, with thoughts of what's likely broken.
- *
- * but now, after discovering 1.3, i do not understand yet how the
- * `--continue` exec fixes things, and am not sure if i want to mess
- * with the `parseNewGoodCommands` logic before i do.
- *
- * [3]
- * the user would never see the `break` command, since just like in 1.1 2),
- * we give the user to edit our own git-rebase-todo file, which contains branch boundaries,
- * and then extracting the normal git rebase commands and creating
- * the git-rebase-todo file for git rebase to run on.
- *
- * ---
- *
- *
- *
- */
 export const gitStackedRebase = async (
 	nameOfInitialBranch: string,
 	specifiedOptions: SomeOptionsForGitStackedRebase = {}
@@ -440,18 +331,18 @@ export const gitStackedRebase = async (
 			initialBranch,
 			currentBranch,
 			// __default__pathToStackedRebaseTodoFile
-			pathToStackedRebaseTodoFile,
-			() =>
-				getWantedCommitsWithBranchBoundariesUsingNativeGitRebase({
-					gitCmd: options.gitCmd,
-					repo,
-					initialBranch,
-					currentBranch,
-					dotGitDirPath,
-					pathToRegularRebaseTodoFile,
-					pathToStackedRebaseTodoFile,
-					pathToRegularRebaseDirInsideDotGit,
-				})
+			pathToStackedRebaseTodoFile
+			// () =>
+			// 	getWantedCommitsWithBranchBoundariesUsingNativeGitRebase({
+			// 		gitCmd: options.gitCmd,
+			// 		repo,
+			// 		initialBranch,
+			// 		currentBranch,
+			// 		dotGitDirPath,
+			// 		pathToRegularRebaseTodoFile,
+			// 		pathToStackedRebaseTodoFile,
+			// 		pathToRegularRebaseDirInsideDotGit,
+			// 	})
 		);
 
 		if (!wasRegularRebaseInProgress || options.viewTodoOnly) {
@@ -1372,6 +1263,7 @@ export async function getWantedCommitsWithBranchBoundariesOurCustomImpl(
 	return extendCommitsWithBranchEnds(repo, bb, wantedCommits);
 }
 
+noop(getWantedCommitsWithBranchBoundariesUsingNativeGitRebase);
 async function getWantedCommitsWithBranchBoundariesUsingNativeGitRebase({
 	gitCmd,
 	repo,