From: Kyle Meyer <kyle@kyleam.com>
To: Oleh Krehel <ohwoeowho@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Merge branch 'maint'
Date: Thu, 10 Sep 2015 18:26:59 -0400 [thread overview]
Message-ID: <87mvwtvrkc.fsf@kyleam.com> (raw)
In-Reply-To: <87lhceo8he.fsf@gmail.com> (Oleh Krehel's message of "Thu, 10 Sep 2015 12:48:45 +0200")
Oleh Krehel <ohwoeowho@gmail.com> writes:
> Why not just cherry-pick the commits from master onto maint, or the
> other way around? That would result in no merge commits.
The result of doing that is IMO worse than many merge commits. For each
fix in maint, you'd end up with two commits that are linked only by a
patch id (if there are no conflicts) and perhaps a reference in the
message (e.g., if -x is used and there are no conflicts). Merging
allows you to manage a large set of changes, including conflicts,
between upstream and downstream branches and to be sure about which
commits a branch contains.
I think cherry picking should be limited to one-off cases where a fix
lands in master and then it is later realized that it's needed in maint.
> I think it should be possible to rebase two branches without having to
> rewrite the public history.
A rebase involving public commits will rewrite the public history
(except for the useless case where calling "git rebase" does nothing
because the branch is already up-to-date).
> As far as I understood, maint is a subset of master, i.e. all commits
> that are in maint are in master as well. Is that correct?
Yes. As long as there aren't any new commits on maint that have yet to
be merged, running
$ git log master..maint
will return empty and
$ git log --oneline --no-merges maint..master
will show all commits new to master.
--
Kyle
next prev parent reply other threads:[~2015-09-10 22:42 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 [this message]
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
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=87mvwtvrkc.fsf@kyleam.com \
--to=kyle@kyleam.com \
--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).