-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branching Policy Draft #73
Comments
At Sun Microsystems (RIP) we used to have a rebase-only workflow, and we had lots of project branches. Sun used this model from circa 1992 to 20010 (and probably still, its descendant products at Oracle) with Teamware and Mercurial, and I suspect now Git. This workflow yields clean, linear history upstream, with project branches archived for posterity. This makes spelunking through history very nice and easy (the branch graph being trivial). In particular there were never any merge commits. Here's how that workflow worked:
Now, for fast moving upstreams it is very important to rebase projects frequently, but if fails to (as I have when contributing to external open source projects), then it helps to have tools that can make the rebase process less painful. I have used this script (a collaboration with @vdukhovni based on original work by him) to successfully rebase a large patch across thousands of upstream commits to PostgreSQL. There are other similar tools like The tools linked above greatly help rebasing across thousands of upstream commits, searching for the commits that introduce conflicts and rebasing to those first, then rebasing further upstream. This makes the conflict resolution process much better than simply merging across thousands of commits because the most specific context (commit) causing each conflict is identified, which helps the developer resolve the conflict. Of course, if one rebases often, then these tools are not nearly as necessary. I highly recommend this workflow! |
Thanks @nicowilliams! This is interesting, we will consider this. |
We used this workflow for OS/Net (the core of Solaris and Illumos) and various other codebases too. OS/Net had several thousand engineers working on it, with many projects large and small. Some projects were huge, like ZFS for example. When pushing very large projects upstream we'd lock the upstream so that no new pushes could happen until after a given project could a) rebase, b) run all their tests, c) complete its push to the upstream -- but this was fairly rare. For open source projects I do not expect one would have the kind of project clone/branch rebasing monthly discipline, so the tools I linked are most useful. Also, the whole clones-as-branches thing was mainly an artifact of Teamware being bad at branching, and that stuck after we moved to Mercurial, but it's not strictly a part of the process -- one can just use branches in the same repo(s). The point of my commentary here is that a) one should not be afraid of "rebase" (many are), b) linear history works really well, c) rebasing with the right tools is easier on the developer than merging. |
@nicowilliams Thanks for those comments. I absolutely want to second those thoughts. Pretty please, with cherries on top keep the history strictly linear. Merge-based workflows are hell to understand and even harder to reconcile for someone working on side branch that gets merged with something else before they're done. At least with a linear history, it is much easier to "replay" and rebase progressively. Let's not introduce merge commits, I don't want to see them in any project I am involved in. |
Typically that would be the I think things that need to be defined that are very important here are:
|
Absolutely! I definitely don't expect us to start using merge commits. |
Anton will share a draft with his thoughts on this. Volunteers to help Anton to be nominated after Anton shares that info. AI @arapov Share a draft, ask for volunteers |
#279 must be kept in mind |
dump of the draft
Problems
Requirements (in descending order of priority)
Likely Design Decisions
There must be a branch which is ready to form the basis of a new feature release at any time
The text was updated successfully, but these errors were encountered: