[topher200]

@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...

[jpgrayson]

Thanks for the recognition!

I think I get the gist of what this interactive script does and how you propose to extend it. A PR for such a script to go into StGit's contrib directory would be non-controversial. Maybe a little higher bar to have this capability as a first-class StGit command.

[sreevisakh]

Thank you for the great tool! I gave it my first try today, and immediately fell in love with it! It's a shame I didn't know about it sooner - could have been a great improvement to my workflow.

[dorian-graph]

> stgit works so much more fluidly and fits great with my mental model of how I want git to behave

Would you mind expanding upon this? I'm really curious.

Have you tried Pijul too?

[sreevisakh]

> Would you mind expanding upon this? I'm really curious.

Not GP, but I share that sentiment. Let me add my two cents. Here are some of the things that confuse me while doing interactive rebases in git:

1. What happens when I delete a commit? Won't the subsequent commits still hold on to its changes, since git uses snapshots? (Nope, that's not how it works)

2. Why does a rebase conflict happen when we try to squash or reorder a few commits? Yes, we can see the original commits, but we have wrack our brains to understand what trips the algorithm.

Git internally uses snapshots to store commits, but uses diffs for rebasing, merging etc. Knowledge of that fact reduces the confusion a bit, but doesn't relieve the cognitive overload. With StGit, they are clearly just patches that you can inspect any time. The reason for any conflicts or results are immediately apparent when you see the patch - much the same way you know why a program misbehaves when you see the source code.

> Have you tried Pijul too?

I have tried Pijul, but didn't stick with it. It didn't feel mature enough yet. However, I sure am going to keep trying until it feels right. What excites me about Pijul is that the author stresses the advantage of patches over snapshots when it comes to merging and rebasing (both are the same in pijul). If the combination of git and stgit is any indication, pijul is likely to be way more powerful. I am excited about its future!

[dorian-graph]

Your comment helps! I've noticed in my own local workflow that I've slowly been gravitating towards similar conclusions that you've made.

Pijul excites me too in this regard! I'm trying to use it concurrently with git in local projects, but perhaps stgit would be a good in-between solution.

[bvrmn]

May be my hints can be helpful. I have much less cognitive load developing multiple features or task switching.

    # coding some-task
    # critical bug approaches
    $ stg refresh; stg pop  # save current changes and pop patch
    $ stg new -m 'fix of critical bug'  # start working on new patch
    # fix fix fix
    $ stg refresh; git review  # commit fix
    $ stg push  # bring some-task to the table again
    # continue to coding some-task

It can look similar to branch model. But devil in details. `stg pull` allows to not think about rebases. pop/push/sink/float allows to toss around patches. I started to think in terms of atomic features and not branches and commits instead.

[dorian-graph]

I think this maps to my model when working on things too. How often I do fixups and rebase is a lot, and I effectively treat the different commits as independent patches, but having a parent (as Pijul allows).

I have also several git worktree's to facilitate working on multiple things at once though, so I don't necessarily need to switch away in my current repo, cause I just go to one of my 4 worktrees that I always have. As I explain this out loud though, it does sound like a very stopgap solution!