I hate git rebase! Hate! Double hate! Hate e to the x!

Sick of merge commit by commit!!!

I believe Torvalds hates it too.. please tell what’s the big deal not having clean history. Enlighten me.

I like git rebase on my own private branch. I combine my commits into one, rebase on top of master. Any conflicts are then in the perspective of my changes being laid on top of the latest master code. Then, when merging to master, my single commit then shows up at the head of master. But, yeah, we're not allowed to do that anymore :(.

Rebase is the most powerful tool of git, hence you can shoot yourself in the foot quite easily with it.

I use rebase constantly at least on pull, my git pull defaults to a `git pull --rebase` as it avoids uncessary merge master into master commits just because a colleague was faster pushing their changes.

On feature branch I own, it's a great way to rebase against the master in order to resolve merge conflicts as soon as they happen. Esp. on long-lasting feature branches (six months) a godsend, while still not riddlign the history with merge commits.

You can also squash a feature branch with loads of work-in-progress commits into one commit.

Need to undo a feature? Revert one commit.

Fucked up the commit message of the previous commit? I can change that.

Rebase is a godsend. Learn it and its implication. Then it just becomes another tool in your toolbox.

Rule of thumb: Don't rebase shared remote branches. Never rebase main branches.

If you own the branch, rebase away.

Even if you do own a branch and are in need of force pushing, always do `--force-with-lease` just to be on the safe side of not trashing others people work.

I think you need to attend my workshops about git xd

Only once had to rebase in my career

@k0pernikus i totally understand what you are saying. I have been using rebase for several years now. So I hope I am not a rebase noob.

Where I have issues are doing pull requests to merge or rebase to master. It’s resolving the conflict commit by commit and a file at a time. If master changed by a lot before your pull request then you are stuck with N commits * M conflicted times O(n*m). Worst case scenario. A merge is O(m).

Of course this is worst case scenario and once a year you do run into it. Larger teams probably run into it more frequently.

There is a time where merging to master makes sense and that option is not available because all the hate towards clean history and maybe abuse of merging frequently going on historically. It’s almost the same rhetoric that is for singletons.

And to further stir the pot...

from : https://lwn.net/Articles/328436/

There are a couple of problems associated with rebasing, though. One of those is that it changes the commit history. Whenever a series of commits is rebased, anybody who was working with the old history is left out in the cold. If a heavily-used tree is rebased, all developers depending on that tree are forced to scramble to readjust to the new reality. The other problem is that rebased patches are changed patches; any testing that they saw may no longer be applicable. That is why Linus tends to grumble hard at trees which have obviously been rebased just prior to the sending of a pull request. The changes in those trees probably worked before the rebase, but the post-rebase changes have not been tested and may not work as well.

And this is Linus Torvalds greatest rant.

Warning: this is like million email thread and you will lose productivity for a month.

READ AT YOUR OWN RISk

yarchive.net/comp/linux/git_rebase.html

Isnt one if the git rules „don‘t lie“? 😅
Rebasing is like telling a lie bc ur changing the history...
I personally don‘t like it at all. I simply don‘t see any benefit t all.
And it‘s dangerous 😂

@mojo2012 I am so glad at least there is one dev who feels the same way about rebase.

Rebasing shouldn't be used lightly, but I do prefer to pull with rebase, as @k0pernicus said. Let's say I made a change on a branch and a colleague made another change on the same branch and was quicker to push it. My branch is out of date with the origin. I can make a merge commit between the branch and the origin, but I prefer to rebase my local commits on the origin. This keeps the history a bit cleaner.

Also for my own pull requests, I frequently rebase my feature branch on top of master. This way when reviewing the commits I want to introduce, you don't see the merge commits with the resolved conflicts and only the changes that are really needed for that feature.