git-autofixup VS stgit

Somewhat (or possibly greatly) related:

Are tools like git-absorb safe/reliable?

"Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run `hg absorb` and the uncommitted modifications are automagically folded ("absorbed") into the appropriate draft ancestor changesets. This is essentially doing `hg histedit` + "roll" actions without having to make a commit or manually make history modification rules."

I haven't wrapped my head around the algorithm. I get that an algorithm can "recollate" a series of commits in a way that yields no commit conflicts, but that's not the same as rearranging and combining commits into a sequence of semantically coherent atomic commits.

---

https://github.com/tummychow/git-absorb

https://github.com/torbiak/git-autofixup

git-autofixup can also be installed by simply downloading the script[1], giving it execute permissions, and putting it somewhere in your PATH. It needs perl 5.8.4+, which is very old, and only depends on the standard library. Git ships with a Perl interpreter on Windows.

If there are any staged changes, git-autofixup only fixes those up and ignores any unstaged ones; otherwise it tries to autofixup all unstaged changes.

[1]: https://github.com/torbiak/git-autofixup/blob/master/git-aut...

The article seems to present a dichotomy between what the author terms a "clean" git history, which he seems to think is a history where multiple commits are squashed into single commits that contain, I guess "one feature", and the unnamed "other" way of doing it, which the author doesn't really elaborate what exactly it is, but he appears to means willy nilly uncurated commits of whatever? To me, both ways he talks about are insane.

With something like stgit[1], it is dead easy to maintain a stack of curated, small un-squashed git-bisectable commits, and your commit history looks like the work of a supernatural genius who knows exactly what he's doing and rarely makes mistakes, and if you have to port your patches (commits) across multiple variants of the same source (think linux drivers ported to multiple distro kernels) that's easy too.

[1] https://stacked-git.github.io/

Pijul needs a 1.0 release if it wants wide adoption. I don't understand why they wait.

Meanwhile, if rebasing on git is an issue, you should probably try stacked-git (https://stacked-git.github.io/). It manages commits as a stack of patches - like quilt, but on top of git.

I just think there's a lot good ideas floating around the git community, for example Stacked Git and gitstatus, but somehow none of this connects with Git developers.

Tangentially related, sometimes I find Stacked Git helpful when figuring out complex features or refactoring. Until it's nearly finished I'm not sure what would be worthwhile submitting as a PR but once it's ready then several smaller PRs are much easier to understand.

It's local stacked PRs and you can jump between them to edit as the ideas evolve.

https://stacked-git.github.io/

But if the nearby code is evolving quickly from other people this can be a bad approach because of merge hell when the work is finally submitted.

Note: there are also tools like https://stacked-git.github.io/ to help manage this.

Maybe checkout StGit: https://stacked-git.github.io/ I have not used it by myself yet, but I think it's capable of what you're trying to do.