From: Nicolas Richard <youngfrog@members.fsf.org>
To: Oleh Krehel <ohwoeowho@gmail.com>
Cc: Achim Gratz <Stromeko@Nexgo.DE>, emacs-orgmode@gnu.org
Subject: Re: Merge branch 'maint'
Date: Tue, 15 Sep 2015 14:16:25 +0200 [thread overview]
Message-ID: <874miv98ti.fsf@members.fsf.org> (raw)
In-Reply-To: <878u8dgesa.fsf@gmail.com> (Oleh Krehel's message of "Fri, 11 Sep 2015 17:24:21 +0200")
Oleh Krehel <ohwoeowho@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
next prev parent reply other threads:[~2015-09-15 12:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 14:50 Merge branch 'maint' Oleh Krehel
2015-09-09 17:30 ` Kyle Meyer
2015-09-10 10:48 ` Oleh Krehel
2015-09-10 15:05 ` Robert Klein
2015-09-10 22:26 ` Kyle Meyer
2015-09-11 11:59 ` Oleh Krehel
2015-09-11 12:58 ` Josiah Schwab
2015-09-11 14:32 ` Oleh Krehel
2015-09-11 15:25 ` Stefan Nobis
2015-09-11 16:15 ` Oleh Krehel
2015-09-11 13:40 ` Achim Gratz
2015-09-11 15:24 ` Oleh Krehel
2015-09-15 12:16 ` Nicolas Richard [this message]
2015-09-11 13:08 ` Suvayu Ali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874miv98ti.fsf@members.fsf.org \
--to=youngfrog@members.fsf.org \
--cc=Stromeko@Nexgo.DE \
--cc=emacs-orgmode@gnu.org \
--cc=ohwoeowho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).