jpgrayson

StGit maintainer here. I have been a jj user for over a year now. It has proven superior to StGit for all of my workloads. I even use jj when maintaining StGit.

An incomplete list of wins vs StGit includes:

- jj makes managing multiple branches fluid, whereas stg has limited tools for managing patches between stacks. 'stg pick' is largely all there is. It's a real dance to move a patch between stacks.

- jj has a much better system for naming changes. I'm super jealous of how jj solved this problem. StGit requires you to name the patches. I added the feature that allows StGit to refer to patches by relative or absolute index in addition to by name. jj's immutable change ids that can be referenced by unambiguous prefix is the correct answer to this problem.

- 'jj rebase' is so vastly superior to stg push/pop/sink/float for reordering changes that I don't even know where to start. It wasn't immediately obvious to me just how flexible, simple, and powerful 'jj rebase' is when I first started using jj, I have learned that it is in its own league relative to StGit's stack ordering story.

- Similarly 'jj squash' makes 'stg squash' look amateurish.

I could go on. If you're a StGit user, you owe it to yourself to give jj a proper try.

Obviously `stg push` and `git push` are different commands, but to your point, yes, they have very different meanings and the overlap is somewhat unfortunate.

StGit uses push/pop in the sense of pushing and popping patches to/from the patch stack. An alternative such as apply/unapply would be valid and could be aliased, but this ship sailed 16 years ago (StGit has been around almost as long as Git) and so is unlikely to change.

Ah ha, someone did use `stg publish`!

I removed it because it was challenging to test and maintain, its semantics are somewhat complex, and it wasn't clear that it provided value to anyone.

If you wouldn't mind making your case on the issue tracker [1], I will reconsider the fate of `stg publish`.

[1] https://github.com/stacked-git/stgit/issues

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.

Good point that StGit's docs could benefit from a compare/contrast with interactive rebase workflows. Thanks!

> slightly nicer interface to interactive rebase

More accurate to say StGit is an alternative interface that does some of the same things as interactive rebase (and more). For me, part of StGit's value proposition is that it is not interactive. A single imperative StGit command may accomplish as much as an interactive rebase session.

Workflows using `git rebase --autosquash` feel more similar to StGit because of their non-interactivity.

With the kind of git workflow you describe, bringing StGit into your tooling/workflow may not be worthwhile.

I'd say if you wanted to do these kinds of stack manipulations a little bit faster or with a little less cognitive overhead (e.g. named patches vs SHA1 hashes), then investing in StGit might pay off.

I generally would agree that using StGit isn't going to be a slam-dunk win for someone who already has a capable workflow using interactive git rebase.

I originally used mercurial and its queues (mq) extension and then found StGit when switching to an organization using git for version control. Thus I got used to the patch-stack model prior to really being exposed to git's interactive rebase.

Some days I wonder if an interactive rebase oriented workflow would be good enough for me, but manipulating the patch-stack with StGit has become so second-nature that even the small amount of extra friction of `git rebase -i` sends me right back to StGit.

Probably the main value-add of StGit versus the git-only workflow described is that StGit makes operations on its stack of patches fast and fluid.

Reordering patches with StGit is trivial with `stg push` and `stg pop`. Arbitrary patches can be combined with `stg squash`. A modification in the work tree can be incorporated into the top-most patch with `stg refresh` or an arbitrary patch in the stack with `stg refresh --patch <patchname>`.

In other words, StGit provides a command vocabulary for performing these kind of patch-stack manipulations in a first-class manner.

But as you note, everything StGit does can be accomplished with plain git--albeit with more or less difficulty depending on the particular stack manipulation goal.

StGit maintainer here.

You are correct that conflicts can occur when pushing or reordering patches. These conflicts are resolved with the regular git mechanisms. I.e. conflict markers in files, use `git add` to mark conflicts as resolved, and then `stg refresh` to update the patch with conflicts resolved.

From what I can tell, there are issues both with sway and alacritty that lead to the current incompatibility.

https://github.com/jwilm/alacritty/issues/97 https://github.com/swaywm/sway/issues/1390 https://github.com/swaywm/sway/issues/1054

From what I gather, alacritty and its window system abstraction layers (glutin & winit) are still somewhat immature w.r.t. their wayland support and that sway, due to the limited nature of its wlc layer, do not quite meet in the middle. As stated in TFA, sway is moving toward a more capable wlroots foundation. And the rust-based alacritty ecosystem is also moving forward with tremendous pace. I have little doubt that class of incompatibility will not exist much longer.

Given the newness of not just wayland, but also alacritty, glutin/winit, rust, and sway, I remain astonished that they work as well as they do. But make no mistake, wayland is new tech and thus has some sharp corners where X11 is a well-established quantity after 30 years of existence.

I have been running sway on Arch on an XPS13 for the past nine months. As a longtime i3 user, I found the transition as painless as I could have hoped given the bleeding-edge nature of the wayland+sway stack.

A couple of findings from my time with sway:

- It was non-obvious how to tweak keyboard options (I like remapping capslock to ctrl). Various XKB_DEFAULT_* environment variables have to be set before starting sway.

- Firefox used to render poorly due to HiDPI scaling issues. Those seem to have been resolved and FF now works like a champ.

- I was excited about using alacritty as a wayland-native terminal, but it does not yet work with sway. It can be run as an X11 client with sway without issue. Hopefully the wlroots situation helps resolve the remaining issues with alacritty.

- Integer-only display scaling made it somewhat challenging to achieve my sweet-spot for my HiDPI display. I ended up not scaling the display (scale=1) and adjusting various font sizes. I'm happy to see that wlroots will enable fractional display scaling.

Sway has made an X11-free system viable for me.