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 17:00:45 +0100 Message-ID: <87d1qi5yz6.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> <87r3eyzt20.fsf@engster.org> <83a8lm1w5s.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458921705 26389 80.91.229.3 (25 Mar 2016 16:01:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 16:01:45 +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 17:01:35 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 1ajUB2-0005iP-Mn for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 17:01:32 +0100 Original-Received: from localhost ([::1]:56865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajUB0-00051M-UK for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 12:01:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajUAR-0004qp-SK for emacs-devel@gnu.org; Fri, 25 Mar 2016 12:00:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajUAO-000844-EH for emacs-devel@gnu.org; Fri, 25 Mar 2016 12:00:55 -0400 Original-Received: from randomsample.de ([5.45.97.173]:42611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajUAO-000839-4s; Fri, 25 Mar 2016 12:00:52 -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=+iieQlh/z9AABJBOdHPqcGQQzqJRgghgeF0uLa9fUa4=; b=l+LvfFiRPrnv2htwdjTLfKi0Q0FbsUeQkyiFRmzWnFYU/h/dBQhOVoQAUVoI4Ks+xfLNziuHdKGjzqZ/fcJG7/0CtqIoYwSqGYOG8YmPuGas9ygyCEa2gA8KMJ89p9AF; 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 1ajUAM-00089P-6c; Fri, 25 Mar 2016 17:00:50 +0100 In-Reply-To: <83a8lm1w5s.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 25 Mar 2016 17:15:11 +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:202226 Archived-At: Eli Zaretskii writes: >> 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: [...] > 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? Well, the cherry-picked commit ad879b7 is now in master's history. The patch of that diff shows that it changes those lines. That we chose to ignore the patch can only be seen by looking at the merge commit 300560577, which references the same 'tree' as the previous merge 'cb4e054e', meaning they both reference they same set of files: > git cat-file 300560577 -p tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 [...] > git cat-file cb4e054e41c -p tree ae2bec4f10425bd61e2a90563edc178d382bb4b8 My best guess is that 'git annotate' does not incorporate that information, but I'm not familiar with the inner workings of that command. Maybe no one bothered to implement it, or maybe it would make annotation even slower. As you well know, Bazaar had a data model which was much more amenable for annotating a file, so I guess it could deal with this issue correctly (I haven't checked, though). >> > 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. Those commits were made part of mainline's history, so how can they possibly be "irrelevant"? It's just that Bazaar had the default to only show mainline (which also confused plenty of people). > What Bazaar would show is the single merge-commit, which (with Bazaar) > "represents" the commits on the merged branch. I forgot how it worked in Bazaar. Did a merge commit hold the full patch information of all merged commits? In any case, that's now the case for Git: a merge commit is a normal commit, simply with more than one parent. >> 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 ;-) I can at least assure you that the patches from those commits are ignored. And I would claim that it worked essentially the same during the Bazaar days. Just fire up 'gitk' and look at old merges from emacs-24 into master; you'll find plenty of backported commits in the merged branches, and bzrmerge dealt with it the same way (with the exception that it did the whole merge in one go, while gitmerge does separate merges). -David