4 ms·

This is all enormously complicated for no reason. If you find the missing tests, just send a PR to add the tests immediately. Why go through all the weirdness

by wffurr 2y ago

This is all enormously complicated for no reason. If you find the missing tests, just send a PR to add the tests immediately. Why go through all the weirdness of stitching into this development branch? Just add the tests and then rebase your WIP branch on it.

__float 2y ago
This was just one example, maybe not a perfect one. I found it to be relatable, though. Sometimes the "add the missing tests" step depends on other work on your branch.
- zbentley 2y ago
  I think the pedantic answer is "if so, your branches/commits are too big." In practice, what you describe is often the case, and having a quick shortcut to do "stick $small_fix in main via a separate branch, but yoink that commit into my branch before that first branch lands on main so I can keep working" would be very useful. Historically, though, I usually addressed this need by copy/pasting the code into separate commits in both branches, and being careful to keep the $small_fix-to-main code and its twin in my larger branch un-drifted and textually discrete to make the eventual merge conflict a rubber-stamp to resolve. Ugly, yes. Maybe I should feel guilty about it, who knows?
  - stouset 2y ago
    That sounds like a lot of work. And it is a lot of work. Even in the best case. I know it is because I used to do exactly this. But more often than not the small fix ends up getting affected by your changes in the branch and then you're in rebase hell again.
a10c 2y ago
I mean that's the point of the article, no? With Jujutsu it's not at all complicated. Sure, you may not agree with the example (and I would say its a little contrived), but rebasing into history to keep a clean progression of commits in a feature branch that is unreleased is something that many people are keen on. Jujutsu also has a bunch of other really useful features like `jj fix` which can run a code linter over a linear commit history (in parallel) and integrate the changes into the commits that should contain the change. This avoids a litany of 'fix formatting' style commits littered through your history.
- arxanas 2y ago
  > rebasing into history to keep a clean progression of commits in a feature branch that is unreleased is something that many people are keen on To give some specific examples, "many people" includes popular open-source projects like Linux and Git itself, as well as large tech companies like Google and Meta, which employ "trunk-based development" (see e.g. https://trunkbaseddevelopment.com https://trunkbaseddevelopment.com).
keybored 2y ago
I don’t know what is supposed to be more straightforward about Just Send a PR. This is a short process broken down into every little step. And every step is just within git/jj. Just Send a PR would involve more steps and indirection.

by wffurr 2y ago

__float 2y ago

This was just one example, maybe not a perfect one. I found it to be relatable, though. Sometimes the "add the missing tests" step depends on other work on your branch.

zbentley 2y ago
I think the pedantic answer is "if so, your branches/commits are too big." In practice, what you describe is often the case, and having a quick shortcut to do "stick $small_fix in main via a separate branch, but yoink that commit into my branch before that first branch lands on main so I can keep working" would be very useful. Historically, though, I usually addressed this need by copy/pasting the code into separate commits in both branches, and being careful to keep the $small_fix-to-main code and its twin in my larger branch un-drifted and textually discrete to make the eventual merge conflict a rubber-stamp to resolve. Ugly, yes. Maybe I should feel guilty about it, who knows?
- stouset 2y ago
  That sounds like a lot of work. And it is a lot of work. Even in the best case. I know it is because I used to do exactly this. But more often than not the small fix ends up getting affected by your changes in the branch and then you're in rebase hell again.

a10c 2y ago

I mean that's the point of the article, no? With Jujutsu it's not at all complicated. Sure, you may not agree with the example (and I would say its a little contrived), but rebasing into history to keep a clean progression of commits in a feature branch that is unreleased is something that many people are keen on. Jujutsu also has a bunch of other really useful features like `jj fix` which can run a code linter over a linear commit history (in parallel) and integrate the changes into the commits that should contain the change. This avoids a litany of 'fix formatting' style commits littered through your history.

arxanas 2y ago
> rebasing into history to keep a clean progression of commits in a feature branch that is unreleased is something that many people are keen on To give some specific examples, "many people" includes popular open-source projects like Linux and Git itself, as well as large tech companies like Google and Meta, which employ "trunk-based development" (see e.g. https://trunkbaseddevelopment.com https://trunkbaseddevelopment.com).

keybored 2y ago

I don’t know what is supposed to be more straightforward about Just Send a PR. This is a short process broken down into every little step. And every step is just within git/jj. Just Send a PR would involve more steps and indirection.