stgit VS misc-gitology

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.

@jpgrayson (since I see you lurking around here) Thanks for maintaining stgit! I've been a recent convert and it's a great workflow improvement. I used to be a big `git rebase -i` user and stgit works so much more fluidly and fits great with my mental model of how I want git to behave. Thanks!

I'd love to add functionality that mimics `git rebase -i`. That is, you would open an editor and be able to select which patches you want on your stack as well as possibly designate patches as 'squash' or 'fix' from your editor. Think of it as `stg sink`, but able to operate on multiple patches at once.

Prior art: this script[1] already performs a re-ordering of commits but in a pretty hacky way. I'd like to productize it!

I'd love to have this new `stg rebase --interactive` be part of the main repo to enjoy the benefits of the existing test suite. My question for you is around how to include the new command with the rest of the tools. Would you want it to integrate with the existing rebase command (`stg rebase --interactive`) or is it something more appropriate for `contrib` (so a new independent command like `stg-rebase-interactive`)?

[1] https://github.com/da-x/misc-gitology/blob/master/stg-rebase...