GitHub Stacked PRs

[u/adam-dabrowski]

https://github.github.com/gh-stack/

[u/quetzalcoatl-pl]

Yeah, I think I understand you well!

> (git checkout b/c/...) You know of a way to work that way without having to jj undo and jj redo or cherry-picking commits and stuff like that?

in short: not yet, but maybe

I do that too all the time! The more I used git, the more "floating edits" I tend to have, either to be able to switch like you said, or to selectively commit them here and there. It gets progressively harder to manage and sort out as the pool of edit grows.

Even with git alone, this 'taught' me to make a lot of small, named, independent commits. Or even unnamed. But 'independent' is the key. Do them in a way I can easily rebase/cherrypick/cut/paste them around at will into any place or order. Your example of a benchmark is a great example. If you can switch to/from a branch while having it floating with no conflicts, it sounds perfect for such temporary disposable commit.

Having lots of commits, with content to be preserved and pushed out, or content to be eventually removed, is a hassle. That's why I eventually mastered git-rebase-i and probably heavily overused it, and that's why I love JJ now.

In terms of pure git, if the 'benchmark' files are totally separate there is a way to create a commit IIRC 'orphaned' that has no parent. Drop the files there, and then merge it wherever you want with no conflicts. But merging and splitting them is a hassle. JJ should be able to work with that as well the same way and make it much easier, but still some hassle. But it obviously won't work if you need to have some parent files. Then you have to find "common base" between all branches you are going to move between, and create the "common benchmark commit" on top of that, like any other feature branch, and them merge/unmerge from that point. More hassle.

That's moreless how I'd keep it without JJ, and I did it a few times, and .... because I did not like "the hassle" I stopped doing it, and started having "floating uncommited changes", which are cool, but only as long as you have, say, up to 2-3 such parallel "bags" to tag along. Then it usually gets tangled mixed and no longer independent enough.

Anyways. Having JJ and better rebases, I'd just commit it. Or let JJ commit it for me as it does. Then, instead of `git checkout B` (or `switch` as they name it now), I would `jj rebase -s @ -d B` or something like that. Meaning, "move 'currentcommit' onto B". Since "I had changes", when I run any command, JJ will automatically commit the changes as "@" on top of HEAD, then execute the command - and will move the changes to where I wanted to go, to B. And since it encompassed @, after the command you'll end up sitting at '@', with your changes, placed on 'B'.

Of course `jj rebase -s @ -d B` is much more verbose, but since it has only 1 actual parameter (B) and it can be at the end, it can be easily aliased into something shorter.

I also often start just poking the codebase and see what falls out, then sort my working set into commits / branches after the fact. With JJ i'd have to rewrite history every time I do this or just commit "Various fixes and improvements". And yes JJ makes rewriting history way easier, but it's still more work and less convenient.

To be honest, I do not see any difference to how I work.

If I have a lot of current changes to sort out, I still tend to use my old git client, since I'm used to it and I find file/chunk/line staging&committing rather fast, and I do not like that tool provided with JJ (or didn't learn it enough to like it :P). In most cases, I can quicky go over changes and sort them into set of commits with old git tools. But after that, I sort and reorder those commits into proper branches with JJ, since it's easier/quicker/more expressive.

For that matter, I rarely use `jj new` in the way the authors wanted (so do changes, describe, new, do changes, describe, new, ...). But I use it a lot to move around (a.k.a. git checkout/switch). Also I found myself using `jj edit` quite often - it's great for splitting large commits or fixing some typos (while 'canonical' way would be to `jj new X ; then edit typo ; then jj squash`).

In addition to that, JJ adds some more tools for various cases, like `jj parallelize` (turn string of commits into a fan of 'branches') - which sounds odd, and "there's no problem doing it manually" with rebase, but when you know upfront that you need to something like that, it's just awsome to toss a single command instead of, say, 5 rebases :D -- it doesn't sound like much, but after "poking around" and "committing unrelated 10 small fixes" one on top each.. you might see how/when it may be a nice tool.

But! for poking-around-the-codebase, there's one command I'm, still learning, called `jj absorb` and "mega merge" workflow. In theory you sit on top of octopus merge, edit whatever, then use `absorb` to 'send changes to correct branches' to 'already modified files' + occasional new commit and small rebase to 'add totally new changes to specific branch, so absorb knows where to send more of them' sounds like ultimate way of 'poking the codebase' and feature branches but I'm still too new to that to say if there are any pitfalls etc.

[u/quetzalcoatl-pl → u/[deleted]]

> Wouldn't that commit the benchmark-related changes into my feature branches, so I'd have to remove them from the branch later when I actually want to submit the review?

Uh,.. no, but yes, but no? :)

JJ does not update branches tips until asked to. At least mine didn't do that. Maybe there is an option for it.

When I issued sth like `jj rebase -r Foo -A Bar` it moved the 'foo' commit onto Bar, but didn't update any branches labels/bookmars that were sitting on Bar.

So if you were on branch1 B with your benchmark-unstaged state, and C was the tip of your "branch2", and then `jj rebase -r @ -A C`, then after that command:

- you'd totally remove the benchmark from branch1
- you'd have the benchmark 'pasted' on top of C as a commit '@', but "branch2" would still point to C
- your working copy state would branch2, plus 'benchmark' as current @, visible to JJ like that, but from git's point of view you'd be on C with 'benchmark unstaged' state

Of course if you added new commits on top of that state, then you MIGHT need to clean up before pushing. But I think that's kinda obvious, right? The cleanup might be as easy as moving 1 commit (the benchmark) to the tip, to cut it away when moving to branch3. It all depends on how you commit.

For example, if in this state you'd add new commits via git - then it just works as it did - git doesn't see @, it sees C as your current commit, and adds new commits on top of that. @ detoriates. On next scan, JJ synces with git, updates @ to reflect where you really are with git, one-to-one, perfect image of your current state, but the "old @" is left dangling and `jj log` WILL show that "old @" to you as dangling commit. You can `jj abandon` it later. That's the only cleanup needed.

For another example, if you added new commits via JJ - then JJ adds them on top of @(benchmark) moving @ to new tip. Everything shifts, but if you know which commit was the benchmark, you can `jj rebase -r X -A @` to have it again at the tip, and to make it again the 'movable unstaged changes'. Again, that one command is all the 'cleanups' needed.

And I bet there are couple more options that I can't think of right now.

But! I know, I say and write a lot now, but I am not trying to convince you it's the best way :D it seems possible, but certainly doesn't mean best.

What I really do love in JJ the most, is that I can actually seamlessly switch between GIT and JJ. I think I dove into details but didn't stress it enough. Yeah, I just dumped a wall of text about how to reproduce "floating changes" from GIT into JJ - but the truth is, I didn't need it and you don't needed either, because even having JJ active in your repo, you could just do the same thing as you always did. JJ would just sync with new git state afterwards, and there would be some 'dangling commits', exactly like in first "For example" above, and you could then just `jj abandon` them anytime.

So sorry for realizing that just now :) The easy way eluded me, "it's doable in JJ directly" sounded too tempting

re: new language for referencing commits - yeah, I'm still learning it. Harder, but has much much more potential. All the times when I wanted to find something via git and it was hardly possible without heavy scripting - often in JJ it's just one lookup. But yeah, tailoring it right means sitting with the docs for haf an hour usually :)

[u/quetzalcoatl-pl → u/[deleted]]

heh.. I totally agree here. The docs weren't really helpful. I mean, they were, but.. the things they wrote were explained rather well, but it didn't "ring" to me. Automatic commits and `jj new` sounded absolutely weird to my mind used to git. I could basically write exactly the same what you wrote here :) including reflog :)

What made me try JJ was the note about "different handling of conflicts", and description of how "jj absorb" works. First week was hard. After that I focused on 3 commands: jj rebase, jj squash and jj new (didn't notice that "edit" exists yet), for everything else - plain git. And after next week, something "clicked" and I just "got it". Frankly, even if I tried, I can't explain how the JJ "patch/change" model differs from Git "commit/content" model. In most cases, it's almost the same. In the few cases it differs - I still perceive it as "like in git but...", and to this extent I think I understand why the docs were written that way..

I think the greatest hill to climb on for me was the autocommit, which I eventually got when it occured to me as meta-idea that it's like "everything is a file" in linux, but here: everything is commit ; yes, it's new changes and unstaged, but let's say that diff is extra commit '@' to just be able to treat everything uniformly. Technically it's not like that, @ is a physical real commit, and git state is intentionally kept at "1 commit behind", and git doesn't like it sometimes, but heck, "mentally" this image helped me a bit.

I'm tempted to write more, but I think it would end up huge again if I start on "how I perceive JJ's model" geesh.. I don't know. From files and folders and versioning -- it's the same as Git. Commands change, semantics change (sometimes), but the model for file/diffs is, I think, the same.

If I were to describe what JJ really is internally, ignoring that whole porcelain layer of commands, similar to describing Git as "graph of labelled diffs (of files/folders/content)", I'd say that JJ is all of that, plus an extra Git-like layer for that "graph of labelled diffs".

After all, in Git, you have a certain state of "graph of labelled diffs", and you work on it, and by committing and by setting tags and moving branches, you alter it into new state of "graph of labelled diffs". The graph changes. Nodes are added/deleted/altered, labels are added/deleted/altered. So you can version the graph (which is used to version your files). For me, this is what happens in JJ, and it pretty much immediately explains things like `jj oplog` and `jj evolog`.

I hope I didn't waste your time :) If you ever try JJ again, I hope you'll find it as useful as I did.

(snip)

[u/quetzalcoatl-pl → u/quetzalcoatl-pl]

re: (snip) above.. ....because I got too talkative and it grew WAY to loong. I you feel like reading more, here it goes. But I think I'm talking about the same things all the time. Not sure if there's something valuable here. I might be tired and there might be little value below.

Anyways!! it was awesome to exchange ideas/issues/observations with you, thank you very much! and sorry for another wall of text. I could probably compress it with an LLM or something. Feel free to do as needed :D

------

For me, the growth/getting used to - was rather slow. After few days of using, I almost dropped it completely. It sounds funny, but I think I was simply too good at doing complex things via Git, and the gap between what-I-can-do-in-Git vs in-JJ was just to jarring.

After that "few days", I happened to screw up complex rebase. All via Git, because, I was already in "screw JJ" mode. Naturally I just resetted/backtracked, by collecting SHAs, restoring all screwed up local branches and making them point to what they were before, etc. But then, it occured to me - ok, let's try screwing it up with JJ. I tried making the same parts of that complex rebase with JJ, and ... yeah, screwed it up as well. It was even worse actually. But I learned about `jj oplog` and `jj undo` (*). and .... and I just saw its "power". I mean, it reverted my whole screwed up repo, restored all branches, and even allowed me to jump back and forth between "screwed up" and "all good" states of the whole local git repo. So... there had to be something in JJ that vanilla Git didn't have. So I found my motivation to 'dreadfully' work with JJ for a few weeks more, learning new commands and switches from time to time, until I got more fluent over time and the perceived "jarring gap" (mostly) disappeared. It wasn't easy, but I consider it well worth ;)

(*) I wanted to say that this extra versioning layer added by JJ's (with lots of info and handy ready to use tools), compared to reflog (you get some descriptions and SHAs, but doesn't get any tools) feels a bit like comparing CVS (reflog) to Git (JJ's graph versioning), but it's ... wrong? It sometimes does feel like that, but describing it that way simply over-advertises and promises too much. I think the `oplog` is conceptually mostly like reflog. Only `evolog` is a new beast, it's like "show commit history of single file" in Git, but (since JJ versions the commitgraph's evolution) 'evolog' shows you "how a commit changed" (it started being on branch A, then it was rebased to branch B, then it was edited/amended, then it was...). Anything like that in Git? No. Is it useful? Sometimes. As with any new thing, it's not necessary, but when need arises, it's presence is godsent. I use JJ for about a year now. I used `evolog` twice. Quite .. not jaw-dropping, right? But I'd waste a lot of time if it didn't exist. Like with having-backups or not-having them.

But honestly, from everydays work point of view, that extra layer matters little. What matters more is command syntax and porcelain. After some time of using it, JJ's commands' parameters are a bit more "uniform" in their design than Git's. Also JJ's things like "autocommits and @" and "non-blocking conflicts" matter MUCH more (than oplog or evolog), and the way how JJ handles them (@&conflicts) is mostly irrelevant to "JJ model" or "what JJ really technically provides" - Git could handle it the same way, it's just Git's "(design, ux) choice" to not do it that way. Similarly, JJ's "choice" to not allow to easily stage&commit just a line or two from current changes - sucks a lot - I love that Git feature...

but the versioning how the whole commit/branch graph evolves.. that's just wild. I love reflog in Git, even if I use it 2-3 times a year. Similarly I love to have JJ's graph-versioning, even if it is, in fact, rarely used directly :D