1. 6

I just discovered stacked git, and am very impressed. It solves a lot of headaches I have been having with git, and I feel like is a better user interface overall for people who like careful commits.

I feel like it might not get the attention is deserves due to (in my opinion) an obscure website and little promotion.

  1. 4

    For the emacs user there is https://github.com/magit/magit-stgit

    1. [Comment from banned user removed]

      1. 2

        er, i think that’s a typo because it links to “stagit - static git page generator” https://codemadness.org/git/stagit/file/README.html

        1. 1

          Oops, you’re right.

    2. 3

      StGit is a command-line application that provides functionality similar to Quilt (i.e. pushing/popping patches to/from a stack), but using Git instead of diff and patch.

      I don’t get a sense for what this does or why I would use it. So I checked the Quilt page…

      Quilt allows you to easily manage large numbers of patches by keeping track of the changes each patch makes. Patches can be applied, un-applied, refreshed, and more.

      …and I’m still confused.

      1. 2

        I agree it is not clear from the site, let me try to explain:

        • It is like a lightweight alternative to one branch per feature.
        • It is very nice for when usually you only do one commit per pull request.
        • It very nice for when you are constantly testing combinations of features as it allows you to avoid creating all sorts of strange hybrid branches.

        edit: I put a long explanation on my site https://acha.ninja/blog/stgit/ with some examples. Let me know if that explanation makes sense, or if it still is confusing.

        1. 2

          Can you help me understand the “development branch” scenario in the tutorial? Is it saying that you’d do your work normally in plain git, and then kind of as a fancy interactive rebase do stg uncommit and then clean up the wip commits?

          Which I guess means this:

          Continue developing, and take advantage of e.g. stg goto or stg refresh –patch to stick updates in the right patch to begin with.

          Implies that once it’s broken out you can go edit whatever patch is interesting before squashing down to a reasonable patch set?

          Thanks, I find this really interesting but am having a hard time imaging my daily routine in the tool.

          1. 2

            I think you are understanding right. doing “stg uncommit –n N” turns the last N commits into patches on the stack, which I guess is sort of like a fancy interactive rebase.

            Once they are broken out like that you can indeed modify them and reorder them.

            1. 1

              Right on, I appreciate your help

      2. 1

        Does anybody have an insight on how this workflow interacts with GitHub? I feel like the next step I’d like is sending each of my patches to a different pull request (independent, if possible).

        I’m actually writing some tooling to make that possible, but the workflow proposed by stgit feels to close to what I want that I’m wondering if I’m not reimplementing something that exists.

        1. 1

          I think what you would do with stgit is work on a master/devel branch + a stack of your patches. When you are ready to do a PR you go “stg publish my-pr-branch; git push github my-pr-branch” to make a branch you can use the github UI to do a pull request with. To update your PR branch after feedback I think you need to republish.

          Unfortunately for that workflow, stg publish doesn’t support force pushing directly to a remote branch, which I think would be quite cool. instead i think you need to rerun stg publish + git push.

          1. 1

            Ok, I just sent a pull request to stgit that makes the github workflow work better.

            https://github.com/ctmarinas/stgit/pull/29

            With this patch you can do something like stgit publish --overwrite some-pr-branch && git push -f some-pr-branch and it will get your current patches into a github pr. Without my patch it creates a new commit each time you update things.

            You will need to manipulate the stack of patches before each publish command to hide patches you don’t with to publish, I am pretty sure something like stg pop dont-want && stg publish will work.

        2. 1

          I like how alternative git interfaces are their own little cottage industry.

          Why have none of them been blessed by the git project itself as the new standard or recommended interface?

          1. 2

            Near as I can tell, they all involve tradeoffs. I use stgit daily, as an adjunct to branch-per-feature. I like it a lot, but would hesitate to recommend it to most developers, because when things go wonky, I usually need to fall back on fairly low-level knowledge of git. I’d imagine the same is true of the other interfaces.