4 ms·

To make it overcomplicated for git just to fake a point doesn't do it for me. I am yet to see a real value to use JJ. Those kind of built-up posts I am seeing

To make it overcomplicated for git just to fake a point doesn't do it for me. I am yet to see a real value to use JJ. Those kind of built-up posts I am seeing about JJ on HN tend to push me in the opposite direction. 1) do your test in your current branch, it's related to what you are doing. 2) commit, co master, co -b newtestbranch, PR it, merge in your branch after. You're going to squash rebase at the end anyway...

roryokane 2y ago
I don’t think the article is overcomplicating the Git commands to falsely represent how complicated Git is. I can easily believe that in some contexts, a Git user really would need to do all the steps the author describes. > 1) do your test in your current branch, it's related to what you are doing. The article describes a scenario where you “feel reasonably assured that green CI will mean you’re on the right track, and you’ve been removing parts of the old parser as you introduce the new”. But this one parser feature you discovered was not under test. “The original parser is half-taken to bits,” so perhaps you already deleted the implementation of that feature, not knowing it was depended on. If the implementation were missing, of course you couldn’t test it on your current branch. Okay, let’s say you didn’t delete the implementation yet – but the implementation calls some of the methods you already modified. If you write a test on your current branch, it would only show that your already-modified parser passes the test. You couldn’t be confident that the expectations in the test you wrote actually match the behavior of the old parser. If the old parser acted differently from your tests (even if it was due to a bug), you need to know about that so you can update callers of the old parser to not rely on that behavior any more. To be confident that your new test accurately describes behavior you need to support, you need to run the new test against the “develop” branch. > 2) … You're going to squash rebase at the end anyway... Why would you assume that? Some teams prefer to express changes as a series of independent commits when possible, and they merge PRs while keeping those individual commits. My current team is one example. On such teams, keeping a Git feature branch’s history organized is a real need. If you wonder why a team wouldn’t just squash rebase, I think the goals of keeping commits separate on the main branch are to make debugging tools such as `git log`, `git blame`, and `git bisect` more useful.
- a10c 2y ago
  > are to make debugging tools such as `git log`, `git blame`, and `git bisect` more useful. *actually work. No point using `git bisect` if you switch to a commit that literally doesn't even compile.
  - maleldil 2y ago
    If you have a commit that doesn't compile, it should have been squashed into another commit before merging the PR. Every commit should be in a valid state. I'm not talking about a full squash merge, just `git rebase -i` to make sure the history makes sense. The final branch history doesn't have to be the same as your development one.
stouset 2y ago
> To make it overcomplicated for git just to fake a point doesn't do it for me I have experienced this exact scenario hundreds of times using git over the past two decades. I’m in the middle of some work, I realize I need to task switch to do some other work, then the work that was mid-flight should depend upon that interim thread of changes. In git it is doable but it is a process, and one that is easily derailed (oh god a chain of failed automatic rebases) that requires keeping state in my head. In jj it is so trivial it doesn’t even register that I did something interesting or special, except when I remember how awful it would have been doing that in git. > You're going to squash rebase at the end anyway No? I’m not?
- frizlab 2y ago
  I’m using worktrees for this. Makes more sense IMHO.
  - stouset 2y ago
    Yes, there are a million first-party and third-party bandaids you can use on top of git to try and approximate a sensible workflow. I was a heavy user of `git-revise`. All of these workarounds just… don't exist in jj, nor do they need to.
    - steveklabnik 2y ago
      (But to be clear Jj has worktrees if you do like that workflow)
      - stouset 2y ago
        Whoops, TIL jj has worktrees!
    - frizlab 2y ago
      It’s not a bandaid, it’s working on two features which should be done on two separate clones. Worktrees avoid having to fully clone the repository, which is cool, but I’d use multiple clones if this did not exist.

roryokane 2y ago

I don’t think the article is overcomplicating the Git commands to falsely represent how complicated Git is. I can easily believe that in some contexts, a Git user really would need to do all the steps the author describes. > 1) do your test in your current branch, it's related to what you are doing. The article describes a scenario where you “feel reasonably assured that green CI will mean you’re on the right track, and you’ve been removing parts of the old parser as you introduce the new”. But this one parser feature you discovered was not under test. “The original parser is half-taken to bits,” so perhaps you already deleted the implementation of that feature, not knowing it was depended on. If the implementation were missing, of course you couldn’t test it on your current branch. Okay, let’s say you didn’t delete the implementation yet – but the implementation calls some of the methods you already modified. If you write a test on your current branch, it would only show that your already-modified parser passes the test. You couldn’t be confident that the expectations in the test you wrote actually match the behavior of the old parser. If the old parser acted differently from your tests (even if it was due to a bug), you need to know about that so you can update callers of the old parser to not rely on that behavior any more. To be confident that your new test accurately describes behavior you need to support, you need to run the new test against the “develop” branch. > 2) … You're going to squash rebase at the end anyway... Why would you assume that? Some teams prefer to express changes as a series of independent commits when possible, and they merge PRs while keeping those individual commits. My current team is one example. On such teams, keeping a Git feature branch’s history organized is a real need. If you wonder why a team wouldn’t just squash rebase, I think the goals of keeping commits separate on the main branch are to make debugging tools such as `git log`, `git blame`, and `git bisect` more useful.

a10c 2y ago
> are to make debugging tools such as `git log`, `git blame`, and `git bisect` more useful. *actually work. No point using `git bisect` if you switch to a commit that literally doesn't even compile.
- maleldil 2y ago
  If you have a commit that doesn't compile, it should have been squashed into another commit before merging the PR. Every commit should be in a valid state. I'm not talking about a full squash merge, just `git rebase -i` to make sure the history makes sense. The final branch history doesn't have to be the same as your development one.

stouset 2y ago

> To make it overcomplicated for git just to fake a point doesn't do it for me I have experienced this exact scenario hundreds of times using git over the past two decades. I’m in the middle of some work, I realize I need to task switch to do some other work, then the work that was mid-flight should depend upon that interim thread of changes. In git it is doable but it is a process, and one that is easily derailed (oh god a chain of failed automatic rebases) that requires keeping state in my head. In jj it is so trivial it doesn’t even register that I did something interesting or special, except when I remember how awful it would have been doing that in git. > You're going to squash rebase at the end anyway No? I’m not?

frizlab 2y ago
I’m using worktrees for this. Makes more sense IMHO.
- stouset 2y ago
  Yes, there are a million first-party and third-party bandaids you can use on top of git to try and approximate a sensible workflow. I was a heavy user of `git-revise`. All of these workarounds just… don't exist in jj, nor do they need to.
  - steveklabnik 2y ago
    (But to be clear Jj has worktrees if you do like that workflow)
    - stouset 2y ago
      Whoops, TIL jj has worktrees!
  - frizlab 2y ago
    It’s not a bandaid, it’s working on two features which should be done on two separate clones. Worktrees avoid having to fully clone the repository, which is cool, but I’d use multiple clones if this did not exist.