Hacker News Reader

Hacker News

Comment by rrwo | Hacker News Reader

Parent Full thread

rrwo

> Rebase has become so integral to my workflow, it's hard to imagine living without it.

Same. I use it to reorganise branches before submitting change requests or merging:

- Combing or splitting commits so that each commit contains a small unit of a logical change

- Reordering commits to related changes are near each other

- Reordering commits so changes that are depended on by later commits occur earlier.

- Rewording commit descriptions to have a lengthy explanation, if needed

- Removing small commits that fix minor typos

It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change.

(I had a colleague who was so used to CVS and couldn't get his head around not using version control as a time tracking device.)

View on HN

> It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change.

This seems a bit like an unhealthy obsession. I would be curious to know if the benefits of having a perfect git history outweigh the costs. A temporal log of changes is good enough for me.

It's not an obsession, and the commit history isn't perfect by any means.

But don't underestimate the value of a good commit history, especially if you are using git blame to understand a change from several years ago. Wading through small typo fixes gets in the way.

Git encourages you to use branches, and rebasing allows you to squash simple typo fixes and minor changes, so you can review a change with a few commits that are easier to understand instead of a dozen.

Used with cherry picking, you can also move commits to other branches. I often find that bigger features changes turn into multiple branches and PRs, which is easier to review.

The cost isn't very much. Maybe a few minutes at most reorganizing a branch.

It also forces me to review the branch before submitting a PR. Sometimes I catch issues or use that as an opportunity to split into multiple PRs.

This all makes sense and I don't doubt that it's worth it for you, I guess I just personally don't lean on commit history that much.

I use git blame to find who touched the code, but not necessarily why. And during reviews I spent most of the time looking at the totality of the code changes (along with tests and PR notes) rather than deducing what's going on by looking at one commit at a time.

Overall I see the history as a log, which is only an artifact and not a product on its own.

Specifically, more atomic commits make rollbacks easier when issues with a change are discovered after merge (e.g., in integration and user acceptance testing). In the very active code bases I've worked on, generating a rollback commit for a single commit is far more straightforward than having to deal with a merge commit that potentially includes other merges (e.g., with `git pull`'s default behavior). In fact, GitHub's pull request UI has it as a single button.

Wouldn't these types of changes more commonly be caught while testing against a branch?

Also in many cases I would think that the fix ends up being even smaller (or bigger) than a single commit (the commit isn't actually atomic).

Maybe the codebases I've worked on weren't active enough for this to be a common problem. But also, having too many cooks in the kitchen may be a part of the problem here too.

Reply on news.ycombinator.com