4 ms·

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up w

by y1n0 5mo ago

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can work with that. I have numerous branches in flight at any given time, and my colleagues do as well. The idea of manually keeping them pointed at the right commit is just nuts. Maybe they've fixed that astonishing choice since then, and I'd give things another go if they did. But branches and worktrees are how I operate. Regarding the article, I have no idea what is going on as I'm red-green color deficient.

jolux 5mo ago
I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new <parent_change_id>` and you have a new branch. Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?
- nine_k 5mo ago
  Imagine that you use jj, while everyone else who works on the repo along with you uses regular git. Is it easy?
  - LoganDark 5mo ago
    I use jj all the time for pull requests, in fact I don't use regular git at all anymore, and it's perfectly easy. Not only can I easily keep all my pull requests properly synced to their base branches, but I can easily and very quickly address review comments, keeping the commit stack clean without having to manually squash or amend or anything of that sort. Honestly it's a lot easier and more efficient than git for me because of how much naturally follows rather than requiring explicit imperative fixups.
  - jolux 5mo ago
    Yes, that describes me at both jobs I’ve had since learning jj. Hence why I asked for specifics: I’m genuinely curious what other people struggle with, partially because I’d like to help them if I can, and partially because it gives me a better understanding of common pitfalls which helps when teaching other people.
  - jgtrosh 5mo ago
    I believe this is the most common scenario, yes. If you're used to actively pushing and pulling from the same branche as your colleagues, you need to learn how to manipulate diverging changes and conflicting bookmarks, but other than that all the jj magic is limited to your local activity.
  - stouset 5mo ago
    Yes, that is the case for almost every repo I’ve ever used jj for. It is a complete non-issue. There is virtually zero friction.
  - rtpg 5mo ago
    yeah nobody "has to know", especially if everyone else is also rebasing etc constantly.
  - tiltowait 5mo ago
    I do this all the time at my job, without issue. I think it's honestly easier than using plain git.
  - Macha 5mo ago
    The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires. Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.
    - igor47 5mo ago
      Are you me? I do feel like I'm starting to forget git as a result of my happy jj use. Thankfully some repos use git submodules, which keeps me at least a little connected
  - Balinares 5mo ago
    Yeah, trivial. Only difference my teammates see is that my commits are much tidier and scoped in a way that's easy to review and think about.
- y1n0 5mo ago
  I think I said named branches, but that is definitely what I mean. I find it strange that people want to work on anonymous branches, but to each their own. I don't so that has no appeal to me. I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
  - justinpombrio 5mo ago
    > it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.
    - em-bee 5mo ago
      that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them. so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
      - igor47 5mo ago
        When I'm working in git, I always start work by creating a new branch with a name. Sometimes the branch becomes something different as I work and then I might rename it or more often just keep a stale name around. But in git commit descriptions come later. In jj, it's the opposite. I start with a change, and I often describe it right away. Branches (bookmarks) come at the end. You could, in jj, tag a new empty change with a bookmark as soon as you create it. You don't have to advance the bookmark -- that the first change in a sequence of changes is tagged with a bookmark is probably as much information as you need?
LoganDark 5mo ago
I don't try to reimplement the git workflow on top of Jujutsu. I like it because I can let go of a bunch of annoying noise that I needed in Git. I like it because rebases don't have to be synchronous and modal. I like it because I can easily edit history, rearrange the commit graph, change commit descriptions, duplicate, and so much more, and even remotely (without having to checkout first). There's so much to love that I never could've even dreamed of under Git. I like Jujutsu so much that I've been working on massive refactors to my tooling in order to support it (example: https://github.com/LoganDark/get-shit-done https://github.com/LoganDark/get-shit-done)
- y1n0 5mo ago
  That's great that it has things you like. I don't do rebasing, except on MRs where I've come to prefer squashing the branch being committed. But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.
  - RobotCaleb 5mo ago
    I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line
    - jwiz 5mo ago
      The delay is on HN side, when people reply too quickly.
      - RobotCaleb 5mo ago
        Oooh, my apologies, then! I misunderstood
  - LoganDark 5mo ago
stouset 5mo ago
I’ll be honest, as a long-time jj user, I actually haven’t the foggiest what you’re talking about with branches being laborious to keep up to date. Can you elaborate?
- y1n0 5mo ago
  I make a commit and the branch doesn't follow it. Bookmark, whatever. That is never a behavior I would want. What purpose does it serve?
  - paradox460 5mo ago
    They added auto advance bookmarks a while ago. You configure which revset bookmarks you want to advance or not, and then it just keeps them at the "head" of a branch
    - cpeterso 5mo ago
      Having to list all the bookmarks you would list to auto-advance in your jj config.toml is a hassle and easy to forget.
      - em-bee 5mo ago
        ideally this should be done automatically when you create the bookmark, maybe with a commandline option: jj bookmark create -a/--auto-advance ...
  - stouset 5mo ago
    Of all the things I was imagining it might be, this was down at the bottom. Personally I’m a huge fan of this approach. If you aren’t, it’s literally just a one-liner (that is trivially made into an alias) to advance a branch name to the most recent revision. And now there’s a feature to do auto-advancing if you want it. Why is it this way? Because jj is designed around revisions being constantly mutated. In git, when I make a commit, I am typically signaling that that a chunk of work is complete. Not always, but usually. In most jj workflows, revisions are mutated constantly during development. A revision being made on the tip of a branch is rarely a signal that that unit of work is finished. It’s even incredibly common to have multiple revisions in a row that are works in progress. Hell, the article we’re all commenting on discusses just such a workflow. If I make five revisions on top of some branch, there is no reason to assume that any of them are ready to be shared, much less all of them. Because of that difference, it makes sense to have an explicit act to move a branch name forward.
throawayonthe 5mo ago
tbh i never actually learned git, but peope working on the same repos with git seem to be ahme ones struggling with named branches... i just do jj rebase and it just works idk
rmwaite 5mo ago
I remember being the big innovation over svn being merging. There were others things, obviously, but the distributed model + easy merges is what I remember.
- y1n0 5mo ago
  Yes, that's true, merging. Which is what made branching a reasonable thing to do.
- kccqzy 5mo ago
  If the big innovation over svn is merging for git, then the big innovation here is conflicts. I hate the fact that git requires you to stop everything and fix the merge conflict when you merge. I especially hate the fact that when rebasing in git sometimes it requires you to solve conflicts one by one. The big innovation here is jj does not require you to resolve merge conflicts in a timely manner; it simply records the fact that there are conflicts in the file and you go about your ways. You don't ever have to abort like `git rebase --abort` or `git merge --abort`.
kccqzy 5mo ago
You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and deletes remote git branches (`jj git push -c` for creation, plain `jj git push` for updates, `jj git push --deleted` for deletions). I do not ever have to think about branch names and it is great!
- y1n0 5mo ago
  Yeah, I don't get it. I'm sure it's because we work differently and that's fine. But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that everyone that likes JJ isn't really doing collaboration.
  - kccqzy 5mo ago
    I collaborate a whole lot. In fact for solo development I use git because jj is overkill for it. Also by default jj prevents you from overwriting commits that exists on the main branch on the remote, but this is what I often do on solo projects. > having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.
  - Macha 5mo ago
    When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.
NamlchakKhandro 5mo ago
Feel the same way about JJ. It feels like Apple vs Linux. Apple being different ... just because (it gives them an artificial moat)
kaladin-jasnah 5mo ago
I like jujutsu simply because (despite my annoyances, which might be because I started using it 2 weeks ago) it's still faster than git. I dislike this as well. I find it easier to keep track of branches with bookmarks, but my workflow still makes things cumbersome. I am usually working with the "megamerge" branches, and I usually want to add commits to my current branch instead of squashing my edits. However, adding commits means I have to add my commit, move my bookmark up to the branch tip (jj tug?), and then rebase the megamerge branch, versus doing nothing for squashing. I also find that when I mess up, I don't really love using `jj op log` to fix it. I want to not be in an environment where it's this easy to destroy history (I feel like git was on the other end of it).
- oscillonoscope 5mo ago
  If I need to move a 'branch bookmark' around a lot, I usually just tie it to an empty commit and then rebase changes before the bookmark.
sakompella 5mo ago
i had this exact friction trying to use jj this weekend. can't fathom for the life of me why i have to run another command that updates the branch to the next commit.
- wocram 5mo ago
  https://github.com/jj-vcs/jj/discussions/3549 https://github.com/jj-vcs/jj/discussions/3549 let's you change this behavior. I think the idea is that branches/bookmarks aren't as necessary as they are with git.
BeetleB 5mo ago
I think much of the problem with this thread is people trying to convince one way is superior/inferior. There are just multiple different ways of working. Some ways fit some people's mental models better. You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should understand that not everyone can handle jj as well as they can. Imagine a different thread where jj users take your exact scenario, and complain about solving the problem with git. You wouldn't understand their pain, because it's not painful for you. This thread is the same, just with jj and git reversed. Personally, I don't see the pain you have. Back when I used git a lot, if I left a branch for a few weeks, I'd forget the name of the branch and would have to list all the branches (and set an alias to sort by and list the last commit dates of each) to discover the appropriate branch name. It's really not all that different from looking at all (recent) heads. Once you get used to this, you stop naming branches - other than to share with others. And when you do share with them, you cannot push (newer) changes because only bookmarked nodes and their parents can be pushed - so just prior to pushing, you advance the bookmark. With the shells I use, it's a few keystrokes before autocomplete/fzf produces the command for me - no mental effort at all. You definitely wouldn't advance the bookmark with each commit. Only when you need to push. And oh man, it's so nice not to have to manage all the branches. With git, I'd routinely go and delete old branches to declutter. With jj, there's simply no need to. The same with stashes. It's really nice not having to do that labor, and simultaneously not dealing with long lists. If this doesn't appeal to you - that's fine. You're not deficient. But understand, nor are those for whom your workflow sucks.
- jaredklewis 5mo ago
  It’s only natural to want to defend one’s preferences with these things. Because unlike with some other preferences, such as what IDE, operating system, or terminal emulator you use, version control systems must be shared. If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.
  - deleted 5mo ago
    [deleted]
arccy 5mo ago
i too work with worktrees (jj workspaces) and prs (requires branches). it's easier if you give up choosing the name of your branch, and instead rely on finding things by description or your workspace name. for prs, I usually start with a single commit, so `jj git push -c` will auto create a named branch based on the change id. And i have template like the following to push to the same branch if i decided to stack commits rather than rewrite: branch-push = ["util", "exec", "--", "sh", "-c", """ name="$(jj log --no-graph --no-pager --color=never -r 'fork_point(@ | trunk())+ & fork_point(@ | trunk())..@' -T '"push-" ++ change_id.short()')" jj bookmark set -r @- "${name}" jj git push -b "${name}" """] you could probably write a similar alias that used your workspace name as the branch name to push to. and descriptions are slightly nicer than branch names, since they can be longer.
LtWorf 5mo ago
I've worked in places where they didn't know about git branches. They only had master. Review was done by having someone sit next to you and scrolling through the code telling what you had changed.
wocram 5mo ago
jujutsu presents the same amount of power with fewer ideas, eg. There is no staging area. It adds new features, like jj undo. The un-learning curve is steep if you already know git very well. https://github.com/jj-vcs/jj/discussions/3549 https://github.com/jj-vcs/jj/discussions/3549 lets you enable automatically advancing bookmarks.

by y1n0 5mo ago

jolux 5mo ago

I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new <parent_change_id>` and you have a new branch. Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?

nine_k 5mo ago
Imagine that you use jj, while everyone else who works on the repo along with you uses regular git. Is it easy?
- LoganDark 5mo ago
  I use jj all the time for pull requests, in fact I don't use regular git at all anymore, and it's perfectly easy. Not only can I easily keep all my pull requests properly synced to their base branches, but I can easily and very quickly address review comments, keeping the commit stack clean without having to manually squash or amend or anything of that sort. Honestly it's a lot easier and more efficient than git for me because of how much naturally follows rather than requiring explicit imperative fixups.
- jolux 5mo ago
  Yes, that describes me at both jobs I’ve had since learning jj. Hence why I asked for specifics: I’m genuinely curious what other people struggle with, partially because I’d like to help them if I can, and partially because it gives me a better understanding of common pitfalls which helps when teaching other people.
- jgtrosh 5mo ago
  I believe this is the most common scenario, yes. If you're used to actively pushing and pulling from the same branche as your colleagues, you need to learn how to manipulate diverging changes and conflicting bookmarks, but other than that all the jj magic is limited to your local activity.
- stouset 5mo ago
  Yes, that is the case for almost every repo I’ve ever used jj for. It is a complete non-issue. There is virtually zero friction.
- rtpg 5mo ago
  yeah nobody "has to know", especially if everyone else is also rebasing etc constantly.
- tiltowait 5mo ago
  I do this all the time at my job, without issue. I think it's honestly easier than using plain git.
- Macha 5mo ago
  The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires. Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.
  - igor47 5mo ago
    Are you me? I do feel like I'm starting to forget git as a result of my happy jj use. Thankfully some repos use git submodules, which keeps me at least a little connected
- Balinares 5mo ago
  Yeah, trivial. Only difference my teammates see is that my commits are much tidier and scoped in a way that's easy to review and think about.
y1n0 5mo ago
I think I said named branches, but that is definitely what I mean. I find it strange that people want to work on anonymous branches, but to each their own. I don't so that has no appeal to me. I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
- justinpombrio 5mo ago
  > it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing. Ah, this is what the description (what git would call the commit message) is for. You can set the description even before you've made any changes.
  - em-bee 5mo ago
    that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them. so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
    - igor47 5mo ago
      When I'm working in git, I always start work by creating a new branch with a name. Sometimes the branch becomes something different as I work and then I might rename it or more often just keep a stale name around. But in git commit descriptions come later. In jj, it's the opposite. I start with a change, and I often describe it right away. Branches (bookmarks) come at the end. You could, in jj, tag a new empty change with a bookmark as soon as you create it. You don't have to advance the bookmark -- that the first change in a sequence of changes is tagged with a bookmark is probably as much information as you need?

LoganDark 5mo ago

I don't try to reimplement the git workflow on top of Jujutsu. I like it because I can let go of a bunch of annoying noise that I needed in Git. I like it because rebases don't have to be synchronous and modal. I like it because I can easily edit history, rearrange the commit graph, change commit descriptions, duplicate, and so much more, and even remotely (without having to checkout first). There's so much to love that I never could've even dreamed of under Git. I like Jujutsu so much that I've been working on massive refactors to my tooling in order to support it (example: https://github.com/LoganDark/get-shit-done https://github.com/LoganDark/get-shit-done)

y1n0 5mo ago
That's great that it has things you like. I don't do rebasing, except on MRs where I've come to prefer squashing the branch being committed. But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.
- RobotCaleb 5mo ago
  I'm excited for your delayed comment. I'm sure going to take note that you delayed it and come back later to read it because I'm super interested in what it is that you've delayed. You know, you can just write the comment instead of holding your place in line
  - jwiz 5mo ago
    The delay is on HN side, when people reply too quickly.
    - RobotCaleb 5mo ago
      Oooh, my apologies, then! I misunderstood
- LoganDark 5mo ago

stouset 5mo ago

I’ll be honest, as a long-time jj user, I actually haven’t the foggiest what you’re talking about with branches being laborious to keep up to date. Can you elaborate?

y1n0 5mo ago
I make a commit and the branch doesn't follow it. Bookmark, whatever. That is never a behavior I would want. What purpose does it serve?
- paradox460 5mo ago
  They added auto advance bookmarks a while ago. You configure which revset bookmarks you want to advance or not, and then it just keeps them at the "head" of a branch
  - cpeterso 5mo ago
    Having to list all the bookmarks you would list to auto-advance in your jj config.toml is a hassle and easy to forget.
    - em-bee 5mo ago
      ideally this should be done automatically when you create the bookmark, maybe with a commandline option: jj bookmark create -a/--auto-advance ...
- stouset 5mo ago
  Of all the things I was imagining it might be, this was down at the bottom. Personally I’m a huge fan of this approach. If you aren’t, it’s literally just a one-liner (that is trivially made into an alias) to advance a branch name to the most recent revision. And now there’s a feature to do auto-advancing if you want it. Why is it this way? Because jj is designed around revisions being constantly mutated. In git, when I make a commit, I am typically signaling that that a chunk of work is complete. Not always, but usually. In most jj workflows, revisions are mutated constantly during development. A revision being made on the tip of a branch is rarely a signal that that unit of work is finished. It’s even incredibly common to have multiple revisions in a row that are works in progress. Hell, the article we’re all commenting on discusses just such a workflow. If I make five revisions on top of some branch, there is no reason to assume that any of them are ready to be shared, much less all of them. Because of that difference, it makes sense to have an explicit act to move a branch name forward.

throawayonthe 5mo ago

tbh i never actually learned git, but peope working on the same repos with git seem to be ahme ones struggling with named branches... i just do jj rebase and it just works idk

rmwaite 5mo ago

I remember being the big innovation over svn being merging. There were others things, obviously, but the distributed model + easy merges is what I remember.

y1n0 5mo ago
Yes, that's true, merging. Which is what made branching a reasonable thing to do.
kccqzy 5mo ago
If the big innovation over svn is merging for git, then the big innovation here is conflicts. I hate the fact that git requires you to stop everything and fix the merge conflict when you merge. I especially hate the fact that when rebasing in git sometimes it requires you to solve conflicts one by one. The big innovation here is jj does not require you to resolve merge conflicts in a timely manner; it simply records the fact that there are conflicts in the file and you go about your ways. You don't ever have to abort like `git rebase --abort` or `git merge --abort`.

kccqzy 5mo ago

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and deletes remote git branches (`jj git push -c` for creation, plain `jj git push` for updates, `jj git push --deleted` for deletions). I do not ever have to think about branch names and it is great!

y1n0 5mo ago
Yeah, I don't get it. I'm sure it's because we work differently and that's fine. But when I'm picking up something someone on the team has left behind because they got pulled on to something else, or are sick, or 5 million other reasons, having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters. I can't help but think that everyone that likes JJ isn't really doing collaboration.
- kccqzy 5mo ago
  I collaborate a whole lot. In fact for solo development I use git because jj is overkill for it. Also by default jj prevents you from overwriting commits that exists on the main branch on the remote, but this is what I often do on solo projects. > having a branch, with a ticket in the name, explaining what the purpose of the branch is, why it exists, what it's current state is, that all matters In my view, all the above information exists not in the branch name, but either in the ticket, or in the commit message. The branch name is purely a superfluous thing that does not convey any information. Many of my colleagues already use a tool to automatically name their branches from the first line of their commit messages, and jj just makes this awkward process straightforward.
- Macha 5mo ago
  When its MR time I use jj push -c and I’ve set my config to auto generate a branch name from the commit message by extracting the ticket ID from the commit message since we have a standard format into something like PROJ-1234-nzytopmn . Since the company I work at enforces squash merge since many coworkers would otherwise have 20 merge, fixup, lint or ci fix commits per MR, auto advancing isn’t relevant. Addressing comments is just squash into that change and repush. We don’t really do long lived branches so the ticket number is enough to find the branch and the commit message explains the change if I need to hand over work.

NamlchakKhandro 5mo ago

Feel the same way about JJ. It feels like Apple vs Linux. Apple being different ... just because (it gives them an artificial moat)

kaladin-jasnah 5mo ago

I like jujutsu simply because (despite my annoyances, which might be because I started using it 2 weeks ago) it's still faster than git. I dislike this as well. I find it easier to keep track of branches with bookmarks, but my workflow still makes things cumbersome. I am usually working with the "megamerge" branches, and I usually want to add commits to my current branch instead of squashing my edits. However, adding commits means I have to add my commit, move my bookmark up to the branch tip (jj tug?), and then rebase the megamerge branch, versus doing nothing for squashing. I also find that when I mess up, I don't really love using `jj op log` to fix it. I want to not be in an environment where it's this easy to destroy history (I feel like git was on the other end of it).

oscillonoscope 5mo ago
If I need to move a 'branch bookmark' around a lot, I usually just tie it to an empty commit and then rebase changes before the bookmark.

sakompella 5mo ago

i had this exact friction trying to use jj this weekend. can't fathom for the life of me why i have to run another command that updates the branch to the next commit.

wocram 5mo ago
https://github.com/jj-vcs/jj/discussions/3549 https://github.com/jj-vcs/jj/discussions/3549 let's you change this behavior. I think the idea is that branches/bookmarks aren't as necessary as they are with git.

BeetleB 5mo ago

I think much of the problem with this thread is people trying to convince one way is superior/inferior. There are just multiple different ways of working. Some ways fit some people's mental models better. You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should understand that not everyone can handle jj as well as they can. Imagine a different thread where jj users take your exact scenario, and complain about solving the problem with git. You wouldn't understand their pain, because it's not painful for you. This thread is the same, just with jj and git reversed. Personally, I don't see the pain you have. Back when I used git a lot, if I left a branch for a few weeks, I'd forget the name of the branch and would have to list all the branches (and set an alias to sort by and list the last commit dates of each) to discover the appropriate branch name. It's really not all that different from looking at all (recent) heads. Once you get used to this, you stop naming branches - other than to share with others. And when you do share with them, you cannot push (newer) changes because only bookmarked nodes and their parents can be pushed - so just prior to pushing, you advance the bookmark. With the shells I use, it's a few keystrokes before autocomplete/fzf produces the command for me - no mental effort at all. You definitely wouldn't advance the bookmark with each commit. Only when you need to push. And oh man, it's so nice not to have to manage all the branches. With git, I'd routinely go and delete old branches to declutter. With jj, there's simply no need to. The same with stashes. It's really nice not having to do that labor, and simultaneously not dealing with long lists. If this doesn't appeal to you - that's fine. You're not deficient. But understand, nor are those for whom your workflow sucks.

jaredklewis 5mo ago
It’s only natural to want to defend one’s preferences with these things. Because unlike with some other preferences, such as what IDE, operating system, or terminal emulator you use, version control systems must be shared. If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.
- deleted 5mo ago
  [deleted]

arccy 5mo ago

i too work with worktrees (jj workspaces) and prs (requires branches). it's easier if you give up choosing the name of your branch, and instead rely on finding things by description or your workspace name. for prs, I usually start with a single commit, so `jj git push -c` will auto create a named branch based on the change id. And i have template like the following to push to the same branch if i decided to stack commits rather than rewrite: branch-push = ["util", "exec", "--", "sh", "-c", """ name="$(jj log --no-graph --no-pager --color=never -r 'fork_point(@ | trunk())+ & fork_point(@ | trunk())..@' -T '"push-" ++ change_id.short()')" jj bookmark set -r @- "${name}" jj git push -b "${name}" """] you could probably write a similar alias that used your workspace name as the branch name to push to. and descriptions are slightly nicer than branch names, since they can be longer.

LtWorf 5mo ago

I've worked in places where they didn't know about git branches. They only had master. Review was done by having someone sit next to you and scrolling through the code telling what you had changed.

wocram 5mo ago

jujutsu presents the same amount of power with fewer ideas, eg. There is no staging area. It adds new features, like jj undo. The un-learning curve is steep if you already know git very well. https://github.com/jj-vcs/jj/discussions/3549 https://github.com/jj-vcs/jj/discussions/3549 lets you enable automatically advancing bookmarks.