From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: Missing changes in merges from emacs-25 to master Date: Fri, 25 Mar 2016 12:38:15 +0100 Message-ID: <87r3eyzt20.fsf@engster.org> References: <56EE8B27.3090208@gmx.at> <83d1qp6on1.fsf@gnu.org> <56EEEE19.4000800@gmx.at> <8360wh6l1a.fsf@gnu.org> <56EEF6DA.3050104@gmx.at> <56EFA47D.8020303@cs.ucla.edu> <83zitr6civ.fsf@gnu.org> <83lh5b66jj.fsf@gnu.org> <8360wf5gmz.fsf@gnu.org> <83wpou4hb4.fsf@gnu.org> <83oaa30wjs.fsf@gnu.org> <87vb4azznm.fsf@engster.org> <83egay25nj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458905937 3592 80.91.229.3 (25 Mar 2016 11:38:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 11:38:57 +0000 (UTC) Cc: johnw@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 12:38:44 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ajQ4g-0006YY-2m for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 12:38:42 +0100 Original-Received: from localhost ([::1]:55577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajQ4f-00045v-DG for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 07:38:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajQ4Q-0003j0-GI for emacs-devel@gnu.org; Fri, 25 Mar 2016 07:38:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajQ4M-0007RM-FI for emacs-devel@gnu.org; Fri, 25 Mar 2016 07:38:26 -0400 Original-Received: from randomsample.de ([5.45.97.173]:41558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajQ4M-0007QZ-6N; Fri, 25 Mar 2016 07:38:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=zReyIO7DKZ72lrvWrJIirvO9lHT4W0BhqN1JKo4xWAM=; b=uZDHMvRrLGpWfmlxkqph6iR6sbq9fuJuIgIlEzkR6macnN6zY2vxyrXLaxDuLtP1P1NFFxWofxyknfcFXixhA0gK/xEogE3C0YM7Jl6p1u8OodU9/u8CLMoLGsh3+nhr; Original-Received: from ip4d1494ed.dynamic.kabel-deutschland.de ([77.20.148.237] helo=isaac) by randomsample.de with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ajQ4K-0002tj-Lu; Fri, 25 Mar 2016 12:38:20 +0100 In-Reply-To: <83egay25nj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 25 Mar 2016 13:50:08 +0300") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202220 Archived-At: Eli Zaretskii writes: >> From: David Engster >> Cc: John Wiegley , emacs-devel@gnu.org >> Date: Fri, 25 Mar 2016 10:15:41 +0100 > >> >> Eli Zaretskii writes: >> > There seems to be another issue with merging to master: we get back >> > commits that were cherry-picked from master to the release branch. >> >> When you merge a branch, you have to merge all of it. But when they are >> marked as 'skipped', they will be merged with strategy "ours", >> effectively ignoring their content. > > What does "their content" include, exactly? The patch. The merge-strategy "ours" means: merge the commit, but take "our" version of everything that would be changed by it. The commit is seen as merged afterwards, but without applying the patch it includes. >> This is how it worked with Bazaar as well. > > With Bazaar, there was a clear mainline, displaying which these > commits wouldn't appear at all. We don't have that with Git, so the > analogy doesn't really help. Bazaar didn't display *any* commits from merged branches by default, whether they were "skipped" or not. So again: gitmerge does that same as bzrmerge did. That we don't invest the effort to keep our mainline on the "left side" is another matter. -David