4 ms·

> 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

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

shaftway 1y ago
> > 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>>
- 1718627440 1y ago
  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
  - kleyd 1y ago
    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.
    - 1718627440 1y ago
      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.
      - 1718627440 1y ago
        s/squash/stash/ <<< "then you also don't need to squash"
  - teo_zero 1y ago
    Ok. JJ wins this round. Go to commit, fix, go to commit is superior to this bunch of commands in every possible way.
Balinares 1y ago
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.
- 1718627440 1y ago
  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.
  - martinvonz 1y ago
    > 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 https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.
    - 1718627440 1y ago
      > ### 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.

shaftway 1y ago

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

1718627440 1y ago
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
- kleyd 1y ago
  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.
  - 1718627440 1y ago
    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.
    - 1718627440 1y ago
      s/squash/stash/ <<< "then you also don't need to squash"
- teo_zero 1y ago
  Ok. JJ wins this round. Go to commit, fix, go to commit is superior to this bunch of commands in every possible way.

Balinares 1y ago

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.

1718627440 1y ago
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.
- martinvonz 1y ago
  > 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 https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.
  - 1718627440 1y ago
    > ### 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.