Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switch to Jujutsu Already: A Tutorial

stavros.io

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Switch to Jujutsu Already: A Tutorial

#141

Post by kleyd »

1718627440 wrote: post #93
shaftway wrote: post #90

Earlier quoted context omitted.

> > You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it. > That sounds the same in Git? I've always struggled with this myself, and would like to update my git knowledge. Can you walk me through the commands to do this? Let's say the commit id is `abcd1234` and it's 5 commits ago. In JJ…

You have the same two options in Git: vim file/with/typo.txt git add file/with/typo.txt git commit --fixup=abcd1234 git rebase --autosquash -i For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended. The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234…

I believe this only works when there are no other uncommitted changes.

So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.

Re: Switch to Jujutsu Already: A Tutorial

#143

Post by martinvonz »

oxceedo wrote: post #130
tcoff91 wrote: post #49

Earlier quoted context omitted.

I am a git expert and I very much prefer jj. It enables workflows that are impractical with git. It’s hard to even imagine these workflows if you only use git because your thinking is constrained by the limitations of your tools. Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python. https://ofcr.se/jujutsu-merge-workflow/

Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git. Which every articles I read on JJ failed to do correctly. My point is not to avoid using other tools to do your job. My point is that if you don't understand something, using a layer on top of it won't help you at all understand things in the long run. I…

FWIW, Drew DeVault wrote such an article but he later took it down (in protest of the Google CLA, I think). You can probably still find it somewhere.

> Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git.

I'm not the person you asked but I can try to explain (I started the jj project, fwiw). Some things `jj rebase` does better than `git rebase`:

* It rebases whole trees/graphs of commits. This is the scenario described at https://stackoverflow.com/questions/17315285/rebasing-a-tree.... Bookmarks/branches are always updated accordingly. `git rebase --update-refs` can do that these days, but still only for one range of commits at a time (i.e. one leaf commit).

* It lets you rip out some commits of a stack and put them somewhere else. This is the `-r` flag. See https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase for some examples. You can also reorder commits by doing things like `jj rebase -r X::Y --insert-after Z` to insert the range of commits from X though Y after commit Z. You can parallelize parts of the graph by doing e.g. `jj rebase -r C --insert-after A --insert-before D` to take an initial linear graph A..D and make C parallel to B.

* It doesn't stop when there are conflicts. You can instead resolve the conflicts when you feel like it.

* It's able to rebase merge commits well, even if there are conflicts and/or conflict resolutions in them. `git rebase --rebase-merges` with the "ort" merge strategy and rerere enabled gets close these days.

* It's about 100x faster by not touching the working copy unnecessarily. `git replay` also does that.

I just sent https://github.com/jj-vcs/jj/pull/7733 to provide some more detail in our "Git Comparison" doc.

Re: Switch to Jujutsu Already: A Tutorial

#144

Post by teo_zero »

1718627440 wrote: post #93
shaftway wrote: post #90

Earlier quoted context omitted.

> > You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it. > That sounds the same in Git? I've always struggled with this myself, and would like to update my git knowledge. Can you walk me through the commands to do this? Let's say the commit id is `abcd1234` and it's 5 commits ago. In JJ…

You have the same two options in Git: vim file/with/typo.txt git add file/with/typo.txt git commit --fixup=abcd1234 git rebase --autosquash -i For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended. The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234…

Ok. JJ wins this round. Go to commit, fix, go to commit is superior to this bunch of commands in every possible way.

Re: Switch to Jujutsu Already: A Tutorial

#145

Post by 1718627440 »

kleyd wrote: post #141
1718627440 wrote: post #93

Earlier quoted context omitted.

You have the same two options in Git: vim file/with/typo.txt git add file/with/typo.txt git commit --fixup=abcd1234 git rebase --autosquash -i For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended. The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234…

I believe this only works when there are no other uncommitted changes. So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.

Sure, but I don't see that as a big deal. It comes down to the fact that git does (interactive) rebases and some merges in the working tree and not in memory. If it is able to do it in memory, then you also don't need to squash, but it needs a point where it could checkout conflicts, without altering data. If you like it to be automatic, you can always set rebase.autoStash or merge.autoStash.

As for effect on the workflow, you can just continue to work and commit and then call autosquash in two weeks, when your about to merge. This also has the benefit, that Git (by default) only alters commits nobody has used yet.

Re: Switch to Jujutsu Already: A Tutorial

#146

Post by 1718627440 »

teo_zero wrote: post #144
1718627440 wrote: post #93

Earlier quoted context omitted.

You have the same two options in Git: vim file/with/typo.txt git add file/with/typo.txt git commit --fixup=abcd1234 git rebase --autosquash -i For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended. The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234…

Ok. JJ wins this round. Go to commit, fix, go to commit is superior to this bunch of commands in every possible way.

That's your opinion.

The second approach has the exact same amount of commands. The first has 2 more. The add is necessary, because Git separates committing into two steps, which has other benefits. If you would want the JJ behaviour you can call commit -a. The autosquash is necessary, because you don't need to use fixup with autosquash, you can also do it alone, which is recommended if this fixes something, that is already in an older release.

Re: Switch to Jujutsu Already: A Tutorial

#147

Post by 1718627440 »

martinvonz wrote: post #134
1718627440 wrote: post #127

Earlier quoted context omitted.

I don't like C++ either, but yes that is also my opinion about Rust. I do already annotate ownership semantics in C, so I don't know why I need a compiler that is opinionated and tells me how I should structure my code. I think Rust would invoke much less resistance, if it weren't so opinionated. As for jj, JJ and Git are much more close than C and Rust. JJ tends to have slightly less commands, but only because what…

> The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered. I don't think it would have been doable. I hear this question/comment sometimes. I sent https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.

> ### Why is Jujutsu a separate project? Why were the features not contributed to Git instead?

> The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.

This doesn't support what you said?

> I don't think it would have been doable.

This only states that JJ has a different user model, with a different structure of commands and flags, not that it magically does things that are impossible in Git.

Btw., you could just link to the commit diff instead. And are you quoting yourself?

-----------

Oops, now I see the issue, you misunderstood me.

> but they just never bothered.

"They" referred to the authors of blog posts. I didn't want to claim, that it would be a good fit to merge the JJ user model with the Git user model. My claim was that the approaches people learn with the JJ user model aren't exactly difficult in the Git model either. People just reconsider their approaches when they touch a new tool with the experience they gained since starting to use Git. They just never considered that approaches with a tool they have been using for years.

Re: Switch to Jujutsu Already: A Tutorial

#148

Post by 1718627440 »

1718627440 wrote: post #145
kleyd wrote: post #141

Earlier quoted context omitted.

I believe this only works when there are no other uncommitted changes. So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.

Sure, but I don't see that as a big deal. It comes down to the fact that git does (interactive) rebases and some merges in the working tree and not in memory. If it is able to do it in memory, then you also don't need to squash, but it needs a point where it could checkout conflicts, without altering data. If you like it to be automatic, you can always set rebase.autoStash or merge.autoStash. As for effect on the wor…

s/squash/stash/ <<< "then you also don't need to squash"

Re: Switch to Jujutsu Already: A Tutorial

#149

Post by martinvonz »

1718627440 wrote: post #147
martinvonz wrote: post #134

Earlier quoted context omitted.

> The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered. I don't think it would have been doable. I hear this question/comment sometimes. I sent https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.

> ### Why is Jujutsu a separate project? Why were the features not contributed to Git instead? > The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new comma…

Ah, I see what you're saying now. Thanks for explaining. I agree with you in principle.

My impression from our Discord server is that quite many JJ users actually are Git experts who have been creating clean commits for years. I'm one of those people. It's not a coincidence that JJ's CLI makes it easy to create clean commits - it's designed for that from scratch.

Re: Switch to Jujutsu Already: A Tutorial

#150

Post by 1718627440 »

martinvonz wrote: post #149
1718627440 wrote: post #147

Earlier quoted context omitted.

> ### Why is Jujutsu a separate project? Why were the features not contributed to Git instead? > The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new comma…

Ah, I see what you're saying now. Thanks for explaining. I agree with you in principle. My impression from our Discord server is that quite many JJ users actually are Git experts who have been creating clean commits for years. I'm one of those people. It's not a coincidence that JJ's CLI makes it easy to create clean commits - it's designed for that from scratch.

Impressive project. I couldn't try it yet, because it requires a newer Rust source than exists in my distro, I'm not going to run random shell code as root and I haven't felt like it is worth to figure out how to bootstrap Rust.

I'm not sure if I would like it, because I care about reproducibility of commits so I want commit hashes to stay the same after a rebase. Does it support --committer-date-is-author-date ?

I'm also somewhat wary of additional layers on top of something.

Post reply on HN