Re: [O] Merge branch 'maint'

[Nicolas Richard]

Oleh Krehel <address@hidden> 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