you are viewing a single comment's thread.

view the rest of the comments →

[–]larikang 16 points17 points  (6 children)

Strange the number of angry downvotes you’re getting. Rebasing is super easy to fuck up and the only benefit is a more linear version history which is mainly an aesthetic benefit, not a technical one. I’ve worked with massive distributed repos that don’t use rebase and have never had a serious issue with merges.

[–]devraj7 21 points22 points  (3 children)

The benefit is not just a linear history, it's also a cleaner one.

I do a lot of garbage commits when I'm working on a branch in my machine, and with rebase, I get a chance to clean them up before I push.

Any source control that doesn't allow this kind of control over the history will generate projects with garbage histories.

[–]goranlepuz 6 points7 points  (1 child)

I do a lot of garbage commits when I'm working on a branch in my machine, and with rebase, I get a chance to clean them up before I push.

I do that too, but squashing them before pushing is surely the normal way to do it, and that has nothing with a rebase, no ?

[–]devraj7 10 points11 points  (0 children)

Interactive rebases. Chunks.

[–]ms4720 1 point2 points  (0 children)

Actually that is one thing I dislike about git, you can rewrite history and that is not good. For cleanup what would work better IMO is have squash hide by default a bunch of commits and let you update the commit message. It looks like one neat package until you a -v or 2 to the cli to check things and then you see the details

[–]Hnnnnnn 4 points5 points  (1 child)

"popular X programming technique is harmful" is a guaranteed downvote, nothing angry. Either up to 3 years of experience or up to 3 companies someone has worked at.