Hacker News Reader

Comment by cryptonector | Hacker News Reader

+1e6.

Rebase workflows are the best. We used them at Sun long before anyone called it rebasing, long before even any VCSes had the feature in any way. It's the only workflow that works in large codebases (monorepos, repo forests) with thousands of developers. Merges stop being interesting very quickly once you've got a) a large number of developers, and b) a high rate of commits on the same codebase -- it's just too much metadata.

Linear history works like a charm and is super easy to understand (because it's linear).

Nobody cares about the internal history of a feature branch that has delivered. One should only care about what mainline bugs were fixed and what features were added -- bugs that never made it to the mainline are simply not interesting at all to developers on the mainline (though admittedly they might be to someone studying developer performance, but then, feature branch history can be kept and archived, just not on the mainline).

View on HN

I find it interesting that many people don't seem to know the "git rerere" option [1], even experienced devs. With long lived feature branches that takes away 95% of the frustration people have with rebasing.

Theoretically, one could also use merges on the feature branch and rebase once at the end of development (as git will auto-remove all merge commits during rebase), but that only works well if you have just a single commit between merges on the feature branch.

[1] https://git-scm.com/book/en/v2/Git-Tools-Rerere

My fastrebase script is even better[0].

[0] https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

My only beef with rebasing is that it seems to fail much more often, whereas merges will usually do the right thing. I realize this is git-specific, but rebases have still given me much more trouble than merges.

I've yet ever to see a rebase workflow fail, and I've been using a rebase workflow since at least 2002.

I do sometimes have to rebase across thousands of commits because I let a branch rot, and that can be hard to rebase, but it can be equally difficult to merge. Instead I use a bisecting rebase approach where I try to rebase straight to the new upstream, and if there's conflicts, abort the rebase and try rebasing to halfway to the new upstream, continuing the process until the rebase was across just one commit, thus I can resolve conflicts directly with the upstream commit that caused them, then restart the process until done.

Hmm, that doesn't match my experience. If I remember correctly, I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again.

Merging doesn't have that problem, it usually just merges fine unless there are conficts in the latest commit (not all previous ones).

> I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again.

is this solved by enabling git-rerere ?

https://medium.com/@porteneuve/fix-conflicts-only-once-with-...

No :/ I had it enabled, which is why I'm surprised it happened. Unfortunately it was long ago that I don't remember details, but I've had my "merges are much easier" opinion reinforced by git multiple times.

No, it's solved by https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

But it's also solved by merging, which is why I don't see the point of rebasing. What's the advantage?

Linear history.

How is that an advantage?

It's much easier to understand linear upstream history!

Also, with this script you get to see which of your commits is conflicting with which upstream commits. That's really important information to me.

I'll give it a shot next time I have conflicts, thanks.

You're welcome. Leave a comment on the gist about how it goes, if you remember!

I'd really like git to have this feature built-in to it...

https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

Git rerere can help with multiple identical conflicts.

Git was first released in 2005. Did other VCS/SCMs have a rebase workflow before git?

I was on a team that “merged forward” from base branches in subversion back then. What I learned later was that was one of the few teams that was a actually doing that in svn.

Yes. Teamware with Casper Dik's "turbo" extensions. We used that at Sun, with a rebase workflow going back much earlier than 2002, but 2002 is when I joined Sun.

Recall that "rebase" == identify the end of the linear history in common between this branch and the upstream, call that the merge base, identify local commits between that merge base and the head of this branch, checkout the upstream head, and cherry-pick (sequentially apply) those commits as if de novo (possibly recording this action in new metadata).

One can implement that even with Fossil or any other VCS that pretends it does not implement rebase and pretends it never will.

Do you have a tool to assist with such rebase? Or something to read? I also prefer linear history without so much superfluous merge metadata, so I'd like to learn more on this.

https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

(Viktor here is https://github.com/vdukhovni/, and I did heavily alter that code.)

It's amazing how I'd consider myself as having a pretty good grasp of Bash programming, certainly more than average among my colleages, and still this code got me already in the second line :-) (never used typeset before)

Thanks for the gist

Reply on news.ycombinator.com