Hacker News Reader

Comment by xg15 | Hacker News Reader

> So to relieve some of that tension and ease up the final merge you’re heading towards, you decide to perform a control merge now and then: a merge of master into your own branch, so that without polluting master you can see what conflicts are lurking, and figure out whether they’re hard to fix.

It is indeed useful, and just so you won’t have to fix these later, you would be tempted to leave that control merge in the tree once you’re done with it, instead of rolling it back with, say, a git reset --hard ORIG_HEAD and keep your graph pristine.

if you use git "linear history" style and will do a rebase at the end anyway, why not do "control rebases" immediately, instead of control merges?

At least from my experience, a rebasing on a branch that has substantially diverged can get painful quickly, however doing many small rebases and trying to keep up with master usually works without many problems.

View on HN

I've long lived by the "rebase early, rebase often" mantra. Makes this sort of thing mostly a non-issue (tho rerere addresses orthogonal problems, like making the same fixes multiple times in a stack of commits). Besides, you should be coding (and testing) against as close as possible to the final state, as otherwise you discover problematic changes later, and have to re-do more.

Personally I slightly prefer merge-y history, as it's more accurate about history... but tooling tends to be a fair bit simpler when it's linear, so I usually stick to linear.

> why not do “control rebases” immediately, instead of control merges?

In this context the “control” in “control merge” is referring to not checking in the result. So if you don’t push the rebase, it would probably have exactly the same effect as a control merge... you’d save the conflict resolutions in the rerere database for later.

If you’re going to push the merge/rebase, then it depends on whether you’re working with other people in your branch. If you are, especially if it’s more than a few people, rebasing could inflict serious merge conflicts on everyone with any pending un-pushed changes. Rebase should be avoided in this case.

Wouldn’t that require a force push after each rebase, which could potentially cause headaches for team members working in the same branch?

Yea I only rebase on branches I’m certain I’m the only one working on.

Although having two people working on the same branch can be a pain anyways.

At that point I’d probably advocate creating a trunk for the N people to work off.

But that of course requires a bit of upkeep as people have to keep it up to date with master.

The simple solution is to not have multiple team members working on the same branch. Branches should be pretty ephemeral.

Reply on news.ycombinator.com