Rebase Considered Harmful

#1

Post by jerodsanto » Fri, Aug 13, 2021, 1:34 PM UTC

Rebase Considered Harmful
fossil-scm.org

Re: Rebase Considered Harmful

#2

Post by jerodsanto » Fri, Aug 13, 2021, 1:35 PM UTC

We discuss this in detail with Richard on next week's episode of The Changelog podcast.

https://changelog.fm

Re: Rebase Considered Harmful

#3

Post by nanis » Fri, Aug 13, 2021, 2:13 PM UTC

I too have thought about this stuff. In many instances, the correct solution depends on the context of the work being done. Are many people working on interrelated parts of the same project? Or, is there a small group of people jumping from one project to the next in any given day with multiple people collaborating in branches at the same time?

> 3.0 Rebase encourages siloed development

You need a strong culturally enforced habit of "commit early, commit often ... rebase early, rebase often, push early push often" with all development happening in branches that are visible to everyone (GitHub, GitLab etc) to avoid this.

I conceptually like a main branch with a clean straight-line history with no merge commits and clear commit messages. It takes discipline. The discipline is helped by a cultural environment where anyone can request changes in any PR, where teams, not individuals, own projects, where clarity of the commit message is equally important as the code, and where is a strong preference for short-lived branches and small PRs.

I also recommend opening a PR as soon as a single commit has been made in a branch and announcing the PR in a dedicated channel so everyone has a chance to follow the development.

This kind of thing is not going to work in every type of project in every organization, but I have developed a preference for it.

Re: Rebase Considered Harmful

#4

Post by neolog » Fri, Aug 13, 2021, 7:40 PM UTC

jerodsanto wrote: post #2

We discuss this in detail with Richard on next week's episode of The Changelog podcast. https://changelog.fm

Do you know why he is doing publicity this year? He was on another podcast recently too.

Re: Rebase Considered Harmful

#5

Post by pm24601 » Fri, Aug 13, 2021, 8:09 PM UTC

Sigh.

Rebase is very useful:

* pre-processing step to a merge. The developer can see that the merge to main will be successful.

* when the branch has cherry picked commits from main, those cherry picks will disappear from the feature branch's commit list.

* rebase also includes the ability to combine commits (get rid of all those WIP commits)

* rebase allows reorder of commits.

rebase is so so much more than just rearrange commit pointers in some "bad" ways.

Failure to include functionality just invites my old fallback when a rebase fails badly.

git checkout main;

git checkout -b new_branch;

git diff -R old_branch | git apply;

git add -A ;

git commit

Removing a tool just invites developers to work around the gap.

Re: Rebase Considered Harmful

#6

Post by Nicksil » Fri, Aug 13, 2021, 8:50 PM UTC

neolog wrote: post #4

jerodsanto wrote: post #2

We discuss this in detail with Richard on next week's episode of The Changelog podcast. https://changelog.fm

Do you know why he is doing publicity this year? He was on another podcast recently too.

>Do you know why he is doing publicity this year? He was on another podcast recently too.

Perhaps he was asked.

Re: Rebase Considered Harmful

#7

Post by gregors » Fri, Aug 13, 2021, 9:26 PM UTC

I'm definitely on the side of rebase being much better in most cases. https://blog.carbonfive.com/always-squash-and-rebase-your-gi...

Re: Rebase Considered Harmful

#8

Post by nemetroid » Fri, Aug 13, 2021, 10:09 PM UTC

Where are the author’s raw notes, false starts, and ultimately discarded segments for this article?

Removing uninteresting cruft before publishing is a good idea, and rebase is a good tool for achieving that.

Re: Rebase Considered Harmful

#9

Post by phamilton » Fri, Aug 13, 2021, 10:39 PM UTC

> if you are using rebase as intended, that means you are keeping private branches. Or, to put it another way, you are doing siloed development.

My average PR represents maybe an afternoon of work before it's reviewed and merged and shipped. With such short-lived branches, siloing isn't a big deal.

I'd suggest that shipping multiple times a day renders rebase's harm pretty irrelevant.

But if we flip that around, are we shipping multiple times a day because we lack tooling and workflows for non-silo'd development? We ship PRs quickly because a long lived PR is hard to maintain and keep up to date. If that wasn't a problem, would we ship less often?

Re: Rebase Considered Harmful

#10

Post by rualca » Fri, Aug 13, 2021, 11:59 PM UTC

pm24601 wrote: post #5

Sigh. Rebase is very useful: * pre-processing step to a merge. The developer can see that the merge to main will be successful. * when the branch has cherry picked commits from main, those cherry picks will disappear from the feature branch's commit list. * rebase also includes the ability to combine commits (get rid of all those WIP commits) * rebase allows reorder of commits. rebase is so so much more than just rea…

> Removing a tool just invites developers to work around the gap.

This.

It's either a clean rebase, or messing the repo history with merge-commits, or merge with no ff and no commit onto HEAD followed by a local commit.

And rebase is far better and far cleaner and far simpler than any alternatives.

And rebase starts to become necessary as soon as two or more people start to work on the same mainline branch. After all, what rebase does is help get your branch (local or remote) updated and tied to the HEAD of a branch without screwing up the commit history. Isn't this one of the most basic usecases for a CVS?