Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebase Considered Harmful

fossil-scm.org

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Rebase Considered Harmful

#11

Post by chousuke »

Rebase is not only useful, but necessary for a distributed VCS to be useful. To be precise, you need to be able to create new commits from old ones using the VCS itself, and if you can do that, you can also rebase.

One of the major reasons I use git for source control whenever I can is that 100% of its features are available at any time for me to use in any way I wish. Rebase allows me to make commits for whatever reason I want at any time, and it's useful because losing committed data is really hard.

When I'm writing code, I put very little effort into how to structure my changes into commits; That's done when I'm preparing a PR or a patch series, when I'm out of the coding mindset and in the "how do I make this reviewable" mindset. When you're contributing to a project, these are two separate tasks that require different approaches. Any false starts and experiments should be documented and expanded on in this phase, because you're communicating with other people. Pushing a series of crappy "asdf" commits on people because "it documents the development process" is lazy and rude.

A tool that requires me to have perfect commits immediately is useless, because getting commits perfect the first time you actually need to commit is not possible.

Re: Rebase Considered Harmful

#12

Post by lytefm »

chousuke wrote: post #11

Rebase is not only useful, but necessary for a distributed VCS to be useful. To be precise, you need to be able to create new commits from old ones using the VCS itself, and if you can do that, you can also rebase. One of the major reasons I use git for source control whenever I can is that 100% of its features are available at any time for me to use in any way I wish. Rebase allows me to make commits for whatever re…

Agreed. And I very much disagree with this paragraph:

> When a developer can go back to the individual check-ins leading up to the current code, they can work out the answers to such questions using only the level of personal brilliance necessary to be a good developer.

When I have to investigate past commits, I hate it to have to dig through a history of WIP commits containing code that didn't make it into the final version.

Of course it's also difficult to dig through a single commit with hundreds or thousands changed lines of code. But when a single commit includes a proper description and an issue reference, it much easier to investigate the developer's full intention than from multiple WIPs.

Re: Rebase Considered Harmful

#13

Post by chousuke »

lytefm wrote: post #12
chousuke wrote: post #11

Rebase is not only useful, but necessary for a distributed VCS to be useful. To be precise, you need to be able to create new commits from old ones using the VCS itself, and if you can do that, you can also rebase. One of the major reasons I use git for source control whenever I can is that 100% of its features are available at any time for me to use in any way I wish. Rebase allows me to make commits for whatever re…

Agreed. And I very much disagree with this paragraph: > When a developer can go back to the individual check-ins leading up to the current code, they can work out the answers to such questions using only the level of personal brilliance necessary to be a good developer. When I have to investigate past commits, I hate it to have to dig through a history of WIP commits containing code that didn't make it into the final…

Realistically, a single commit is not going to contain hundreds of thousands of lines of changes unless they're generated code or something.

I'm not advocating that you should merge branches by squashing all commits into one lump; that's definitely wrong. I think in terms of patch series, where each patch is a single commit that does something, and each feature is a series of patches consisting of stand-alone refactorings, bug fixes and new APIs required to implement the final feature.

But how I actually end up with that clean set of 1-n final commits in a PR or mailing list submission is no-one's business but mine.

Re: Rebase Considered Harmful

#14

Post by omegalulw »

chousuke wrote: post #11

Rebase is not only useful, but necessary for a distributed VCS to be useful. To be precise, you need to be able to create new commits from old ones using the VCS itself, and if you can do that, you can also rebase. One of the major reasons I use git for source control whenever I can is that 100% of its features are available at any time for me to use in any way I wish. Rebase allows me to make commits for whatever re…

+1 rebase and merge aren't weird things that git does, they are fundamental to any version control system. They are pretty much necessary for collaboration or if you want to edit history.

Re: Rebase Considered Harmful

#15

Post by mbrodersen »

chousuke wrote: post #11

Rebase is not only useful, but necessary for a distributed VCS to be useful. To be precise, you need to be able to create new commits from old ones using the VCS itself, and if you can do that, you can also rebase. One of the major reasons I use git for source control whenever I can is that 100% of its features are available at any time for me to use in any way I wish. Rebase allows me to make commits for whatever re…

Completely agree. Rebasing is absolutely necessary and useful when multiple developers are committing different fixes all the time.

Re: Rebase Considered Harmful

#16

Post by chousuke »

nanis wrote: post #3

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 e…

Personally, I like merge commits. I often merge feature branches even if I could do a fast-forward, because the merge commit explicitly documents the set of patches that made up a feature. The question isn't really about merge vs. rebase; you should use both.

There's absolutely nothing wrong with a merge commit that says "merge feature-xyz into master"; you get a neat side path in the commit graph that contains the changes that made up xyz. Once you merge a branch however, you should delete it. Don't merge branches multiple times, and don't merge master into your feature branches.

You want to think of features as sets of individual logical changes, ie. patch series. I nearly always rewrite the commits in a branch before I merge it, to create a clean patch series. That usually means I also rebase the changes, but it's not always necessary.

Post reply on HN