3 ms·

To be clear, what I'm advocating for is that feature branches get rebased regularly by the developer until PR-time and a clean merge into the mainline. I usuall

by idop 4y ago

To be clear, what I'm advocating for is that feature branches get rebased regularly by the developer until PR-time and a clean merge into the mainline. I usually recommend squashing to one commit but do not insist. I can definitely see how those intermediate commits can provide more information, but there's a tradeoff. More often than not, they do not provide me much value, and instead give me bloat, so I prefer to keep things simple. Telling developers not to do something is like telling a kid not to push that red button. The average developer chooses what's easiest _right now_ and thinks it's someone else's job to fix the mess at PR time. And they're afraid, because that one time five years ago they ran a rebase without knowing what it does, and lost some code without knowing it's actually right there in the reflog, and since then they are deathly afraid of Git. I know how to use log and diff and all the others quite well, but most don't. So I'm trying to make things easier on everyone in the long term, not the short term.

P5fRxh5kUvp2th 4y ago
"Why doesn't git bisect work?" "well, it landed on this rebased commit that's huge. I guess it was a kind of useful, just not as useful as we'd like".
- firesloth 4y ago
  Haha, true! On the other hand, is that better or worse than running into a string of "wip" commits that had the code in a broken state.
- Dylan16807 4y ago
  But if the alternative is that it's ten commits and most of them don't work anyway, the bisect takes longer to give you the same lousy information.
  - P5fRxh5kUvp2th 4y ago
    That's not the alternative, who develops like that? It's like the first time I saw the essay calling ORM's the "vietnam of the software industry". I remember reading it and wondering who the hell would use ORM's in that manner? Apparently a lot of people, but if you're using rebase because you don't know how to create commits that build and are functional then I submit the issue is with you.
    - idop 4y ago
      > That's not the alternative, who develops like that? As an independent contractor working with many different companies, unfortunately, virtually everybody.
firesloth 4y ago
I've been recommending making a git tag before rebasing. eg: git tag -f pre-rebase

by idop 4y ago

P5fRxh5kUvp2th 4y ago

"Why doesn't git bisect work?" "well, it landed on this rebased commit that's huge. I guess it was a kind of useful, just not as useful as we'd like".

firesloth 4y ago
Haha, true! On the other hand, is that better or worse than running into a string of "wip" commits that had the code in a broken state.
Dylan16807 4y ago
But if the alternative is that it's ten commits and most of them don't work anyway, the bisect takes longer to give you the same lousy information.
- P5fRxh5kUvp2th 4y ago
  That's not the alternative, who develops like that? It's like the first time I saw the essay calling ORM's the "vietnam of the software industry". I remember reading it and wondering who the hell would use ORM's in that manner? Apparently a lot of people, but if you're using rebase because you don't know how to create commits that build and are functional then I submit the issue is with you.
  - idop 4y ago
    > That's not the alternative, who develops like that? As an independent contractor working with many different companies, unfortunately, virtually everybody.

firesloth 4y ago

I've been recommending making a git tag before rebasing. eg: git tag -f pre-rebase