From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Missing changes in merges from emacs-25 to master Date: Fri, 25 Mar 2016 17:15:11 +0300 Message-ID: <83a8lm1w5s.fsf@gnu.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> <87r3eyzt20.fsf@engster.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458916195 1353 80.91.229.3 (25 Mar 2016 14:29:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 14:29:55 +0000 (UTC) Cc: johnw@gnu.org, emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 15:29:54 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 1ajSWh-00016q-9T for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 15:15:47 +0100 Original-Received: from localhost ([::1]:56392 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajSWg-0006So-EO for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 10:15:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajSWT-0006Qw-7a for emacs-devel@gnu.org; Fri, 25 Mar 2016 10:15:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajSWS-0008Pp-3P for emacs-devel@gnu.org; Fri, 25 Mar 2016 10:15:33 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajSWN-0008PA-7m; Fri, 25 Mar 2016 10:15:27 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4854 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ajSWL-0007N3-Fb; Fri, 25 Mar 2016 10:15:25 -0400 In-reply-to: <87r3eyzt20.fsf@engster.org> (message from David Engster on Fri, 25 Mar 2016 12:38:15 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:202223 Archived-At: > From: David Engster > Cc: johnw@gnu.org, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 12:38:15 +0100 > > >> 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. I'm not sure I understand the meaning of this. Let me ask a more specific question, about the particular commit that bothers me. Once again, it is this commit from the emacs-25 branch: commit ad879b7f7e049160c45361fe8a12580801ba035b Author: K. Handa Date: Thu Jan 14 21:48:44 2016 +0900 Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt) * src/ftfont.c (ftfont_shape_by_flt): Fix previous change. Access the second glyph only when there are enough glyphs. (cherry picked from commit 9835757013569673854b692ccbb58bfb3c3ed1f7) It was originally made on master, as 9835757, then cherry-picked to emacs-25 as above and committed there as ad879b, and then merged back to master in 3005605, with this log message: commit 3005605776955593e0b416de9e1ebf158114343e Merge: cb4e054 ad879b7 Author: Paul Eggert Date: Sat Jan 30 11:43:27 2016 -0800 ; Merge from origin/emacs-25 The following commits were skipped: ad879b7 Backport:fix previous change of src/ftfont.c (ftfont_shape_by_flt) 4a3db0f support rendering of wider range of combinging characters by ftfont After all this, what would you expect "git annotate" to show on the master branch as the commit that introduced the affected source lines? Shouldn't it show the original commit, i.e. 9835757? Because it doesn't show that, it shows ad879b7 instead. If that's expected behavior, then I _really_ don't understand what "skip" means here, since it sounds like it didn't use the "ours" strategy, according to your definition. What am I missing? > > 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. Of course: those commits were on other branches, so they are irrelevant for the mainline. What Bazaar would show is the single merge-commit, which (with Bazaar) "represents" the commits on the merged branch. > 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. I didn't yet voice any complaints about what gitmerge does, I'm just saying that something seems wrong in the DAG. Whether it was gitmerge that produced that remains to be seen; for now, we cannot even agree on what we actually see there, and whether it constitutes a problem ;-)