4 ms·

My biggest issue with Juijitsu and Sapling (especially) is compatibility with a repo where nobody else uses these tools. Sapling's problem is pretty obvious: I

My biggest issue with Juijitsu and Sapling (especially) is compatibility with a repo where nobody else uses these tools. Sapling's problem is pretty obvious: I would have to get others to use FBs merge stack tool and get that past security approval. JJ? I spent a day trying to rebase/merge from trunk into my PR branch and truly fucked it up in a way that I have never managed with plain old Git - Google results were pretty scarce and unhelpful. For Git, I `switch foo; rebase main; push --force-with-lease`, for JJ (apparently) I `rebase -b main -d foo` - great! How do I access the results of the rebase and update my PR branch? How do I force push that branch? It feels like the documentation is in the same place that Git was in during the early days - I assumes you are deeply familiar with the idiomatic workflow. The effort put into the migration guide is minimal[1]. /rant [1]: https://martinvonz.github.io/jj/latest/git-comparison/ https://martinvonz.github.io/jj/latest/git-comparison/

steveklabnik 2y ago
Sorry you had a bad time with jj! > Google results were pretty scarce and unhelpful. This is true, the Discord is very active and helpful though: https://discord.gg/bKWAbtpH https://discord.gg/bKWAbtpH Discord isn't for everyone, but you can get help quickly. You can also ask questions as GitHub Discussions: https://github.com/martinvonz/jj/discussions https://github.com/martinvonz/jj/discussions > How do I access the results of the rebase and update my PR branch? So, one small difference between jj and git is that jj's branches don't move automatically if you add new changes on top of them. In the next jj release, "branches" will be renamed to "bookmarks" to kinda emphasize this difference, even though they're used for git interop. Additionally, there's some discussion about what making branches/bookmarks move like git branches move could mean, with an experimental setting to give that a try. With all of that said, when you rebased, it shouldn't have changed where the head of your branch was pointed to, so you shouldn't have needed to actually move anything here. This is a side effect of the change/commit distinction: the branch points to a change, so when you rebase your stuff, the commits will change, but the change will not. That means all you needed to do was... > How do I force push that branch? `jj git push` will force push all of your changes. > It feels like the documentation is in the same place that Git was in during the early days - I assumes you are deeply familiar with the idiomatic workflow. I agree that the documentation isn't in a super awesome place yet, but I think the cause is kind of the opposite: there isn't really one idiomatic workflow, but instead a few common ones, and a hesitation to demand that a specific workflow is idiomatic. That being said, I have an in-progress tutorial that I have been waiting for two recent changes to land (one being the branch -> bookmark rename, the other being a different rename (obslog -> evolog)), that is intended to land upstream once I'm done with it: https://steveklabnik.github.io/jujutsu-tutorial/ https://steveklabnik.github.io/jujutsu-tutorial/ After that, if I can keep finding the energy, I'd love to keep improving the documentation, but I have a lot less FOSS energy than I used to, so we'll see.
- Minion3665 2y ago
  oh hey- that's your guide? It's awesome, highly recommend to anyone else wanting to give jujutsu a try! ... I read through it when I didn't know what jujutsu was. It not only convinced me to try jujutsu out, but laid the groundwork for me to get started really quickly and easily.
  - steveklabnik 2y ago
    It is, thank you and I'm glad to hear it!
- zamalek 2y ago
  Thanks for taking the time to address my concerns. I am still very much open to trying it again in the future, but just like you I have time constraints and have to find a time box for it. What I would really like to see an extremely simple walkthrough that covers some really basic scenarios without the ceremony of setting up a new JJ repo, for busy people who want to pilot something new - that covers all of: * Central repository using branches (single remote) OR GitHub-style forked repository (multiple remotes) * Merge-based workflow OR rebase-based workflow, both without conflicts Using github.com/martinvonz/jj as an example repo - show us how to draw the entire owl Take me from opening a terminal in order to make my changes, to creating a commit with those changes, merging/rebasing the trunk to my branch, to pushing it to my remote branch. Remember: I (and the rest of the 80%) have a job to do, so we want the cliff notes to reach success, and then we can dive deeper into things as we encounter them naturally. Once you have the trivial workflow out of the way you can progressively disclose other things. For example, for conflict resolution/merging, you could start with an example that's already in a conflicted state and walk through that - i.e. an example that solely focuses on a specific issue. Remember, your new users want to achieve things first - think from their perspective "oh shit, this rebase has resulted in a conflict, what do I do?" or "my team uses gitflow, how do I interact with that?" Tiny little tutorials that cover common scenarios go a lot further than a monolithic detailed tutorial.
  - steveklabnik 2y ago
    Thank you for the input! > just like you I have time constraints and have to find a time box for it. 100%, even with jj itself, it took me two or three tries hearing about it before I decided to try it, and then twice of giving it a shot before it stuck. Once it stuck, it really stuck, for me at least. > Once you have the trivial workflow out of the way you can progressively disclose other things. This is sorta kinda how I have my tutorial set up, but I suspect I go a bit slow for you at the start. I tend to be more of a bottom-up learner myself, and this is a common criticism of the Rust book. Part of the reason I wanted to wait before upstreaming what I have is so that I have the freedom for more radical changes, so I will give what you're saying some consideration. I 100% agree that workflows are super super important to demonstrate, it was honestly kind of some of the motivation to write this tutorial in the first place.
aseipp 2y ago
> Sapling's problem is pretty obvious: I would have to get others to use FBs merge stack tool and get that past security approval. You don't have to use Sapling's integration at all, FWIW. I completely avoided PR functionality when I first started using it, and would just do a branch for every commit (which is what it would do for you, anyway.) I think almost every tool imaginable can do a diff between branches? > for JJ (apparently) I `rebase -b main -d foo` These arguments are backwards. What you want is to flip the -d and -b switches which mean "destination" and "branch" respectively: jj rebase -d main -b whatever-branch-you-want jj git push -b whatever-branch-you-want You don't have to switch to any branches or do anything else to make this work. These two commands will basically work no matter what the state of the tree is. > It feels like the documentation is in the same place that Git was in during the early days Yeah. We've talked about this. It's not great but we have so many things going on right now, nobody has totally taken over documentation. Steve Klabnik's Jujutsu tutorial is very popular and we've even considered asking if we could rewrite our documentation using it, but again, so little time. https://steveklabnik.github.io/jujutsu-tutorial/introduction/introduction.html https://steveklabnik.github.io/jujutsu-tutorial/introduction... (I'm one of the Jujutsu developers, in case it wasn't clear from the last paragraph.)
Aerbil313 2y ago
If you come into jj and try to just use it without going through the tutorial[1] you’ll just gert frustrated and disappointed. Jj is not git and the workflow is very much different, arguably far better than git. I went through the tutorial first and had no issues at all and I actually understood the how it works under the hood as a VCS. With git I’ve never understood how it works and just used clone, rebase, commit, push. Seems like you had a bad day. Luckily the day I tried it it occurred me to first RTFM. 1: Steve Klabnik’s tutorial is arguably the best one atm.

steveklabnik 2y ago

Sorry you had a bad time with jj! > Google results were pretty scarce and unhelpful. This is true, the Discord is very active and helpful though: https://discord.gg/bKWAbtpH https://discord.gg/bKWAbtpH Discord isn't for everyone, but you can get help quickly. You can also ask questions as GitHub Discussions: https://github.com/martinvonz/jj/discussions https://github.com/martinvonz/jj/discussions > How do I access the results of the rebase and update my PR branch? So, one small difference between jj and git is that jj's branches don't move automatically if you add new changes on top of them. In the next jj release, "branches" will be renamed to "bookmarks" to kinda emphasize this difference, even though they're used for git interop. Additionally, there's some discussion about what making branches/bookmarks move like git branches move could mean, with an experimental setting to give that a try. With all of that said, when you rebased, it shouldn't have changed where the head of your branch was pointed to, so you shouldn't have needed to actually move anything here. This is a side effect of the change/commit distinction: the branch points to a change, so when you rebase your stuff, the commits will change, but the change will not. That means all you needed to do was... > How do I force push that branch? `jj git push` will force push all of your changes. > It feels like the documentation is in the same place that Git was in during the early days - I assumes you are deeply familiar with the idiomatic workflow. I agree that the documentation isn't in a super awesome place yet, but I think the cause is kind of the opposite: there isn't really one idiomatic workflow, but instead a few common ones, and a hesitation to demand that a specific workflow is idiomatic. That being said, I have an in-progress tutorial that I have been waiting for two recent changes to land (one being the branch -> bookmark rename, the other being a different rename (obslog -> evolog)), that is intended to land upstream once I'm done with it: https://steveklabnik.github.io/jujutsu-tutorial/ https://steveklabnik.github.io/jujutsu-tutorial/ After that, if I can keep finding the energy, I'd love to keep improving the documentation, but I have a lot less FOSS energy than I used to, so we'll see.

Minion3665 2y ago
oh hey- that's your guide? It's awesome, highly recommend to anyone else wanting to give jujutsu a try! ... I read through it when I didn't know what jujutsu was. It not only convinced me to try jujutsu out, but laid the groundwork for me to get started really quickly and easily.
- steveklabnik 2y ago
  It is, thank you and I'm glad to hear it!
zamalek 2y ago
Thanks for taking the time to address my concerns. I am still very much open to trying it again in the future, but just like you I have time constraints and have to find a time box for it. What I would really like to see an extremely simple walkthrough that covers some really basic scenarios without the ceremony of setting up a new JJ repo, for busy people who want to pilot something new - that covers all of: * Central repository using branches (single remote) OR GitHub-style forked repository (multiple remotes) * Merge-based workflow OR rebase-based workflow, both without conflicts Using github.com/martinvonz/jj as an example repo - show us how to draw the entire owl Take me from opening a terminal in order to make my changes, to creating a commit with those changes, merging/rebasing the trunk to my branch, to pushing it to my remote branch. Remember: I (and the rest of the 80%) have a job to do, so we want the cliff notes to reach success, and then we can dive deeper into things as we encounter them naturally. Once you have the trivial workflow out of the way you can progressively disclose other things. For example, for conflict resolution/merging, you could start with an example that's already in a conflicted state and walk through that - i.e. an example that solely focuses on a specific issue. Remember, your new users want to achieve things first - think from their perspective "oh shit, this rebase has resulted in a conflict, what do I do?" or "my team uses gitflow, how do I interact with that?" Tiny little tutorials that cover common scenarios go a lot further than a monolithic detailed tutorial.
- steveklabnik 2y ago
  Thank you for the input! > just like you I have time constraints and have to find a time box for it. 100%, even with jj itself, it took me two or three tries hearing about it before I decided to try it, and then twice of giving it a shot before it stuck. Once it stuck, it really stuck, for me at least. > Once you have the trivial workflow out of the way you can progressively disclose other things. This is sorta kinda how I have my tutorial set up, but I suspect I go a bit slow for you at the start. I tend to be more of a bottom-up learner myself, and this is a common criticism of the Rust book. Part of the reason I wanted to wait before upstreaming what I have is so that I have the freedom for more radical changes, so I will give what you're saying some consideration. I 100% agree that workflows are super super important to demonstrate, it was honestly kind of some of the motivation to write this tutorial in the first place.

aseipp 2y ago

> Sapling's problem is pretty obvious: I would have to get others to use FBs merge stack tool and get that past security approval. You don't have to use Sapling's integration at all, FWIW. I completely avoided PR functionality when I first started using it, and would just do a branch for every commit (which is what it would do for you, anyway.) I think almost every tool imaginable can do a diff between branches? > for JJ (apparently) I `rebase -b main -d foo` These arguments are backwards. What you want is to flip the -d and -b switches which mean "destination" and "branch" respectively: jj rebase -d main -b whatever-branch-you-want jj git push -b whatever-branch-you-want You don't have to switch to any branches or do anything else to make this work. These two commands will basically work no matter what the state of the tree is. > It feels like the documentation is in the same place that Git was in during the early days Yeah. We've talked about this. It's not great but we have so many things going on right now, nobody has totally taken over documentation. Steve Klabnik's Jujutsu tutorial is very popular and we've even considered asking if we could rewrite our documentation using it, but again, so little time. https://steveklabnik.github.io/jujutsu-tutorial/introduction/introduction.html https://steveklabnik.github.io/jujutsu-tutorial/introduction... (I'm one of the Jujutsu developers, in case it wasn't clear from the last paragraph.)

Aerbil313 2y ago

If you come into jj and try to just use it without going through the tutorial[1] you’ll just gert frustrated and disappointed. Jj is not git and the workflow is very much different, arguably far better than git. I went through the tutorial first and had no issues at all and I actually understood the how it works under the hood as a VCS. With git I’ve never understood how it works and just used clone, rebase, commit, push. Seems like you had a bad day. Luckily the day I tried it it occurred me to first RTFM. 1: Steve Klabnik’s tutorial is arguably the best one atm.