emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Oleh Krehel <ohwoeowho@gmail.com>
To: Achim Gratz <Stromeko@Nexgo.DE>
Cc: emacs-orgmode@gnu.org
Subject: Re: Merge branch 'maint'
Date: Fri, 11 Sep 2015 17:24:21 +0200	[thread overview]
Message-ID: <878u8dgesa.fsf@gmail.com> (raw)
In-Reply-To: <msulkm$6td$1@ger.gmane.org> (Achim Gratz's message of "Fri, 11 Sep 2015 15:40:38 +0200")

Achim Gratz <Stromeko@Nexgo.DE> writes:

> Am 11.09.2015 um 13:59 schrieb Oleh Krehel:
>> What is the purpose of maint exactly?
>
> It's a bit short on the explanation side, but does that help?
>
> http://orgmode.org/worg/dev/index.html

It does help a bit.

> Also (not exactly the branch model ORg uses, but explains the issues
> in more detail):
>
> http://nvie.com/posts/a-successful-git-branching-model/
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> http://williamdurand.fr/2012/01/17/my-git-branching-model/
>
>> In Emacs git repository there's
>> master and emacs24. All commits apply to master first, while some are
>> cherry picked onto emacs24. The emacs24 branch will never be merged into
>> master: it's divergent and that's fine.
>
> You might want to check your facts (most recently, see for instance
> commit 59db4308b546).  Realitity simply doesn't conform to your
> world-view and the conclusions you draw from it are similarly
> distorted. Cherry-picking from master to emacs24 is actually fixing a
> mistake made when committing a bug-fix to master.

Well, there are only 5 commits since the last tag in the emacs-24
branch, the top one being a cherry-pick. I don't really see harm in
them, there are more cherry-picks in that branch.

What exactly is the advantage of having 2 commits in master for 1 commit
in maint? Besides the ease of merging maint into master and master into
maint or release? This ease of merging comes at the cost of ease of
examining the master, which is where most of the work should be anyway.

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? 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?

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.

  reply	other threads:[~2015-09-11 15:23 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 [this message]
2015-09-15 12:16             ` Nicolas Richard
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=878u8dgesa.fsf@gmail.com \
    --to=ohwoeowho@gmail.com \
    --cc=Stromeko@Nexgo.DE \
    --cc=emacs-orgmode@gnu.org \
    /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).