Oleh Krehel <ohwoeo...@gmail.com> writes: > Now, please check my facts again. Is it true that Emacs doesn't have > maint and has instead a bunch of hanging branches for each release that > aren't meant to have master merged into them on release?
In emacs, the current emacs24 branch will never be used for a release unless there is a serious concern with emacs-24.5 that needs a emacs-24.6 release. So it sees no commits, except for the few commits that "really should go into 24.6 if it is ever released". Before 24.5 was released, emacs-24 had more commits, and was regularly merged backinto master. > If so, what > exactly is the advantage in applying a patch to a stable branch and then > merging it into master, instead of applying to patch to master and > cherry-picking it to the stable branch? We don't want to create to distinct commits for a given change, because they will not be related in the git sense (the « DAG ») and it will be more difficult to e.g. list every branch that has a given change. > I'm not saying that I'm a Git expert or anything, far from it. But I > observe the Git history of Emacs and Org regularly, and both models seem > to be working fine for the users, release-wise. But the master branch of > Emacs looks a lot better than the master branch of Org, and I don't > understand the trade-off that Org's model offers to compensate for that > lack of prettiness. IIUC Org has a similar model, except that maint is merged far more often into master (basically after every commit to maint). Probably this is done so that `master branch users' don't need to wait before seeing the bugfixes that go to maint. -- Nicolas
