December 4th, 2021

```shell git config --global alias.rebaseraw = rebase git config --global alias.rebase = git-multi-rebase # idk if it'd work, todo verify```

idk if we should have a config like in [[(hidden) zmiEcf1EP]].

{{[[TODO]]}} would take some safety measures?

would launch `git-rebase -i`

https://github.com/Shopify/git-chain

{{[[TODO]]}} check if js has such lib

https://github.com/wsteelman/git-utilities

reading the title of this:

dude! what i want is stacked diffs!!

maybe i should rename multi-rebase to stacked-rebase?

the tool itself, gh-stack, seems pretty cool, but it's github-specific, and has many things that suck about it. i want mine to be git-specific (lol), with potentially adaptors for creating new PRs, editing PR titles etc., but that's less relevant if we figure out the core functionality.

{{[[TODO]]}} i also realized that `new-branch-end` (or `branch-end-new`, if `ben` is good for shortname) is a little subtle -- if you're inserting a new branch (or branches) __between 2 existing ones__ (always the case here) in the same rebase, if you e.g. have normal ordering of 1., 2., 3., etc., now you'd have to add another level, e.g. if inserting between 2. and 3., it now becomes: 1., 2.1, 2.2, 3. perhaps we don't need to modify the existing 2. into 2.1, or actually, perhaps it should be 1., 2., 3.1, 3.2, because we're taking & splitting commits from 3., not from 2. (since a number marks the __end__, __not__ the beginning.). again, how do we retain e.g. github comments here? not worth to focus on right now, but good to keep in mind.

https://news.ycombinator.com/item?id=27305521

https://github.com/epage/git-stack

https://github.com/ezyang/ghstack

we could have a template repo that included the `run.sh` script, which would have the current logic, but the `get_secrets` would be extracted into a separate script, `get_secrets.sh`, and it'd take $1 as which secret getter to use, and people could contribute different secret getters.

this would make it reusable; people could contribute different getters (e.g. i use keepass-xc-cli, someone might use gpg, etc etc)

{{[[TODO]]}} get rid of custom domain.

{{[[TODO]]}} i think the manual intervals are clearly identifiable - 1. i prefix the commit with `deploy (manual): ` instead of `deploy: `, 2. they differ more in time (e.g. commits of 1 session's multiple runs are close to each other, and to find the last one, you gotta go 1 by 1 from the latest one, and keep averaging the time deltas, and compare the current commit with the one before it).

(hidden) Vka1d8zqs [[(hidden) MvgWIN74D]]

(hidden) 0MW1VGNbM

(hidden) eKD1ByQ5H

(hidden) 6YBivOi4h

(hidden) t2HR4PwlY

https://libgit2.org/

dude why is this not common knowledge? i've never seen anyone use this. this should be made very clear somewhere like git-scm or git's own source (in their Documentation/contrib or similar guide)

{{[[TODO]]}} i think we'll need to save this info, similarly to how you have to do it manually w/ [[(hidden) zmiEcf1EP]] - to make sure that if someone else wants to edit (which almost never should be the case, unless ofc it's you yourself, just on a different device), then they'd have this protection already

e.g. if someone were to add a new branch (even you yourself, in a different device), and forgot about it - we're kinda messed up, as opposed to being able to fully recover.

{{[[TODO]]}} maybe instead of re-creating branches, we could, starting from the first one (excluding the initial one), `git reset --hard` it to the previous branch (before taking safety measures ofc ofc), and then run cherry-picks from the latest branch?

aha! this is why i myself was confused and even added the `options.addNewlineAfterBranchEnd` option - it's a completely wrong way to think about it! & when you internalize the "boundaries", you're all set.