Up the Lazy River

[billroper]

The problem when you have long-lived branches in Git (or, I presume, pretty much any version control system) is that you need to keep them updated so that the source code there vaguely resembles what's on the main line. When there's any substantial velocity on the main line, it's worse.

It's worse.

I have two different branches that I've had to do major projects on that I haven't been allowed to merge back to the main line. One of them I hadn't done any work on since early November, which was the last time that I updated it from the main line.

Today's merge took well over an hour as I tried to reconcile the changes and it *still* won't compile correctly.

And now I have an email that says that the *other* branch needs to be updated.

Which is why I keep saying that we need to merge these things.

(We have one branch that is over a year old, because the work I did there hasn't been merged yet. Eek!)

Comments

[mdlbear]

If you're actually merging rather than rebasing, you should try rebasing. It often gives better results because it applies each commit in the branch sequentially rather than trying to get to the current state in one step. Conflicts also get resolved incrementally, so they're usually not as large.

As usual, your mileage may vary.

[billroper]

Oh, it does. This was actually a rebasing.

*sigh*

[mdlbear]

Oh. Yeah; that's a problem.

At one point I considered writing a script to rebase and rebuild my older branches every time master changed.