From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kyle Meyer Subject: Re: Merge branch 'maint' Date: Thu, 10 Sep 2015 18:26:59 -0400 Message-ID: <87mvwtvrkc.fsf@kyleam.com> References: <87twr37il4.fsf@gmail.com> <87y4gfpkjy.fsf@kyleam.com> <87lhceo8he.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaAXl-0001cw-6z for emacs-orgmode@gnu.org; Thu, 10 Sep 2015 18:42:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaAJ8-0006C8-FT for emacs-orgmode@gnu.org; Thu, 10 Sep 2015 18:27:58 -0400 Received: from mail-qg0-f49.google.com ([209.85.192.49]:33282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaAJ8-00068z-3N for emacs-orgmode@gnu.org; Thu, 10 Sep 2015 18:27:06 -0400 Received: by qgev79 with SMTP id v79so48601391qge.0 for ; Thu, 10 Sep 2015 15:27:04 -0700 (PDT) In-Reply-To: <87lhceo8he.fsf@gmail.com> (Oleh Krehel's message of "Thu, 10 Sep 2015 12:48:45 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Oleh Krehel Cc: emacs-orgmode@gnu.org Oleh Krehel 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