Comment by Balinares | Hacker News Reader

Comment by Balinares | Hacker News Reader

Parent Full thread

I don't have major pain points with git either (mainly just that rebase merge conflicts can get awful to deal with), but I just love jj and I'm not looking back.

It turns out there were a lot of things that I was not doing with git because with git it would have been painful.

Now my PRs are split into human-sized commits that each contain a set of changes that make sense together, and I keep moving changes around during development to keep the history tidy, until it's time to send the pull request. If a commit introduces a typo, the typo fix should go into that commit so the typo never happened in the first place and you don't get reviews like "please fix this" and then "oh wait I see you fixed it in a later commit".

And sure, with git you could checkout the faulty commit, amend it, then amend -a and hope no one was looking, and rebase your dev branch onto the amended commit and it will often even work. Or rebase -i, sure -- have fun with it if the typo was 12 commits ago.

So I just never did that because augh.

With jj it's trivial. 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.

No more rebase hell. No more deleting the checkout and pulling it clean because things went sideways in a way that would be hell to fix manually -- jj takes snapshots after every mutation and rolling back is easy. No more squashing on merge to sweep the messy commit history under the carpet. No more juggling index and staged files and stashed files and all that messy business. Everything is just suspiciously straightforward. To think this could have been our lives all along!

And I'm not looking back.

It's not that I dislike git. It's just that I love jj.

> Now my PRs are split into human-sized commits that each contain a set of changes that make sense together, and I keep moving changes around during development to keep the history tidy, until it's time to send the pull request. If a commit introduces a typo, the typo fix should go into that commit so the typo never happened in the first place and you don't get reviews like "please fix this" and then "oh wait I see you fixed it in a later commit".

That's my workflow in Git. It is sometimes painful, but only because other people don't do that.

It is less work, if you use git --fixup=old-commit-hash and then use git rebase --autosquash. The --fixup step can even by automated, by using git-absorb, but this needs to be installed separately.

> 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?

> No more deleting the checkout and pulling it clean because things went sideways in a way that would be hell to fix manually

When do you need to do that? The only case in which I messed up my repo, was when I had a harddrive crash and recovered commits manually from git objects, because the other files were corrupted.

> rolling back is easy.

Yes, that seams a bit easier, but reflog still exists.

> No more squashing on merge to sweep the messy commit history under the carpet.

This is just as well a stupid idea in Git and I hate that. This seams to be cultural and is not suggested by the tool itself.

> No more juggling index and staged files and stashed files

I find these useful, but you can also use Git without them. Just always use commit -a and commit instead of stashing.

> > 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 I'd do this:

    vim file/with/typo.txt
    jj squash -into abcd1234 file/with/typo.txt

Or if I was feeling more pedantic I'd do:

    jj edit abcd1234
    vim file/with/typo.txt
    jj edit <<my latest commit ID>>

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 was the last time you modified these lines.

The second approach is this:

    git rebase -i abcd1234~
    # do 's/pick abcd1234/edit abcd1234/' in your editor
    vim file/with/typo.txt
    git rebase --continue

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.

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

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.

Of course! Likewise, you can do in C++ everything you can do in Rust. And yet Rust is there and fast growing in popularity. As it turns out, how to do things, and at the cost of what externalities, matters no less than what you can do.

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 are flags in JJ are separate commands in Git. The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered.

Also I prefer refining stuff we already have instead of throwing it all in the bin and stating it's obsolete.

> 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.

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.

We don't have --committer-date-is-author-date. I don't think we've had a single request for it until now.

That flag seems a bit weird, though. Wouldn't you want to keep whatever the committer date already was? Why would you want to reset it to the author date? Of course, after you have passed the flag once, any subsequent uses will have the same effect as keeping the committer date, so maybe that's why it's good enough. Maybe it works the way it does for historical reasons (I happened to see that it used to be passed to `git am` back when `git rebase` was based on that).

I was curious so I searched the repo, the only mentions of this flag boil down to people being confused about there being two dates, and being okay with the current behavior.

Are you talking about Git or JJ?

I'm talking about jj.

Did it sound like an explicit decision from jj or just being inherited from Git?

The jj git backend happens to update only one of the two timestamps. There's not a lot of talk about the author date on the jj issue tracker.

I did not dig into the history of the code, so I can't say if it was an explicit design decision or just how it was implemented. Since there hasn't been a lot of demand to change anything here, I didn't see any active discussion about the choice.

EDIT: oh I see martin has said 'we just followed git' here: https://news.ycombinator.com/item?id=45599741

I do keep the committer date when I intentionally modify some single special commit, but when I just keep changing stuff I don't do it. In my opinion this date is only useful if the committer and author are also different, for example when you pull some random change suggested in some forum you can put author and date from the forum in and yourself and the time of commit in the committer.

> Wouldn't you want to keep whatever the committer date already was?

Note, that when you create a new commit, the beginning committer and author date are always equal. So the original one is always the author date.

I find this flag useful, because it means that I can keep rebaseing and still reproduce the same commit hashes. This is really useful for asserting that nothing changed when the commit hash is equal or that really something changed when it is different. Otherwise the commit hash changes for all commits you touched in the rebase and you constantly need to verify if there was a change or not.

I haven't used JJ, so does it work the same in JJ than in Git? Did you introduced it intentionally or does the committer fields only exists, because this is how it is in Git and you had no reason to change it.

Do you mean if jj has separate author and committer timestamps? Yes, we simply followed Git there. I didn't really question it. There has been some discussion about simplifying it to just one timestamp, however. You can probably find that discussion somewhere in our issue tracker if you're curious.

Or do you mean if jj updates the committer timestamp while leaving the author timestamp unchanged? Yes, that's also the same as what Git does.

Thanks, the first was what I asked, but the latter was also nice to know.

Reply on news.ycombinator.com