3 ms·

I never touch the git rebase at once in my 10 years of programming. It's born to solve a problem little people face ? I'm not sure though.

blowski 5y ago
On large monolithic repos with a lot of people committing features independently, rebase helps reduce the noise in the history. If you mostly work on small repos (e.g. microservices) or repos with few contributors, then it makes sense you haven't needed rebase.
- revskill 5y ago
  Not quite. We have a workflow to resolve conflict though. All needed is just git merge, git pull. You need workflow, not git rebase.
  - blowski 5y ago
    A lot of very smart people disagree with you.
  - bonzini 5y ago
    Then you must have never used "git bisect"? Or only bisect on the first parent?
3np 5y ago
How do you make your commit history clean and reviewable when submitting a PR? How do you keep your local branch up-to-date with upstream without a mess of merge commits? I use it continuously throughout any workday, if I'm doing contributions that day. It's also a good idea to set your pull strategy to rebase, as recommended here: https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merge https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merg... git config --global pull.rebase true
- KronisLV 5y ago
  > How do you make your commit history clean and reviewable when submitting a PR? I've seen cases where people don't care in the slightest about the list of commits in any PR/MR, but instead just look at the diff view to see the code changes. At least that's how it's been in every single project that i've ever been a part of. Most also don't use rebasing at all and don't do squashing commits into a single one for that particular PR/MR either. That said, there is probably merit to using rebase and squashing as well, though many fail to see it or gain anything useful from it.
- WorldMaker 5y ago
  Merge commits are quite navigable. We have DAG traversal as basic interview questions all the time in this industry for multiple reasons. They are only a mess if you call it that and generally refuse to use traversal tools such as --first-parent.

blowski 5y ago

On large monolithic repos with a lot of people committing features independently, rebase helps reduce the noise in the history. If you mostly work on small repos (e.g. microservices) or repos with few contributors, then it makes sense you haven't needed rebase.

revskill 5y ago
Not quite. We have a workflow to resolve conflict though. All needed is just git merge, git pull. You need workflow, not git rebase.
- blowski 5y ago
  A lot of very smart people disagree with you.
- bonzini 5y ago
  Then you must have never used "git bisect"? Or only bisect on the first parent?

3np 5y ago

How do you make your commit history clean and reviewable when submitting a PR? How do you keep your local branch up-to-date with upstream without a mess of merge commits? I use it continuously throughout any workday, if I'm doing contributions that day. It's also a good idea to set your pull strategy to rebase, as recommended here: https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merge https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merg... git config --global pull.rebase true

KronisLV 5y ago
> How do you make your commit history clean and reviewable when submitting a PR? I've seen cases where people don't care in the slightest about the list of commits in any PR/MR, but instead just look at the diff view to see the code changes. At least that's how it's been in every single project that i've ever been a part of. Most also don't use rebasing at all and don't do squashing commits into a single one for that particular PR/MR either. That said, there is probably merit to using rebase and squashing as well, though many fail to see it or gain anything useful from it.
WorldMaker 5y ago
Merge commits are quite navigable. We have DAG traversal as basic interview questions all the time in this industry for multiple reasons. They are only a mess if you call it that and generally refuse to use traversal tools such as --first-parent.