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 20:33:55 +0300 Message-ID: <8360wa1myk.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> <83a8lm1w5s.fsf@gnu.org> <87d1qi5yz6.fsf@engster.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458927285 19389 80.91.229.3 (25 Mar 2016 17:34:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 17:34:45 +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 18:34:40 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 1ajVdA-0004c6-2B for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 18:34:40 +0100 Original-Received: from localhost ([::1]:57261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajVd4-0004EH-9X for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 13:34:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajVcs-0004Dy-AO for emacs-devel@gnu.org; Fri, 25 Mar 2016 13:34:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajVcr-0005TK-86 for emacs-devel@gnu.org; Fri, 25 Mar 2016 13:34:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajVcm-0005St-IW; Fri, 25 Mar 2016 13:34:16 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4992 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ajVcl-0005hd-7Q; Fri, 25 Mar 2016 13:34:15 -0400 In-reply-to: <87d1qi5yz6.fsf@engster.org> (message from David Engster on Fri, 25 Mar 2016 17:00:45 +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:202233 Archived-At: > From: David Engster > Cc: johnw@gnu.org, emacs-devel@gnu.org > Date: Fri, 25 Mar 2016 17:00:45 +0100 > > > 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. So I guess the fact that a commit was skipped during a merge is something that is so hard to see that perhaps the entire issue of skipping is moot with Git, and we shouldn't be bothered by it. > >> > 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 Not in Bazaar's philosophy. They are part of the DAG, but not of the branch's mainline. > > 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? Yes. > I can at least assure you that the patches from those commits are > ignored. I believe you. It's just strange and confusing that so many Git commands show information that indicates the opposite, and the truth is only shown by looking at the low-level objects and comparing hashes.