From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Fri, 03 Apr 2015 17:00:42 +0900 Message-ID: <87pp7lhc9h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83twx2xoc8.fsf@gnu.org> <87619hke3u.fsf@uwakimon.sk.tsukuba.ac.jp> <551A3F17.6020903@math.ntnu.no> <20150331085055.GA2871@acm.fritz.box> <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331104935.GB2871@acm.fritz.box> <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331214347.GH2871@acm.fritz.box> <20150401103225.GA2633@acm.fritz.box> <87h9t080gx.fsf@javad.com> <83384jsx3o.fsf@gnu.org> <83pp7nrfdn.fsf@gnu.org> <83a8yqr226.fsf@gnu.org> <831tk2qvz5.fsf@gnu.org> <87384ii26v.fsf@uwakimon.sk.tsukuba.ac.jp> <83wq1tptvp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428048067 1352 80.91.229.3 (3 Apr 2015 08:01:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Apr 2015 08:01:07 +0000 (UTC) Cc: sorganov@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 03 10:00:58 2015 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 1YdwXA-0007Aq-Ui for ged-emacs-devel@m.gmane.org; Fri, 03 Apr 2015 10:00:57 +0200 Original-Received: from localhost ([::1]:32929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdwXA-0002gJ-4G for ged-emacs-devel@m.gmane.org; Fri, 03 Apr 2015 04:00:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdwX6-0002fx-8d for emacs-devel@gnu.org; Fri, 03 Apr 2015 04:00:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdwX5-00074e-0P for emacs-devel@gnu.org; Fri, 03 Apr 2015 04:00:52 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:46469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdwX0-00072r-5t; Fri, 03 Apr 2015 04:00:46 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E842F1C3898; Fri, 3 Apr 2015 17:00:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A7B9C120EC9; Fri, 3 Apr 2015 17:00:42 +0900 (JST) In-Reply-To: <83wq1tptvp.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:184816 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Cc: Sergey Organov , > > emacs-devel@gnu.org > > Date: Fri, 03 Apr 2015 07:40:40 +0900 > > > > Eli Zaretskii writes: > > > > From: Sergey Organov > > > > > > Each commit has zero or more pointers to parents, usually 1. Merge > > > > commit is commit that has more pointers to parents than 1 (usually 2). > > > > That's all about the meta-data. Simple, eh? > > > > > > And that meta-data needs to be brought in as part of the merge, in > > > addition to changes to the tree. > > > > No. That's an important difference between git and other DVCSes. > > "git merge" does a 3-way merge in a tree that corresponds to a > > previously committed state, and sets up some (hidden) metadata that > > help automate the following multi-parent commit. Optionally it will > > initiate that commit. > > > > The meta-data must already be present in the repo pointed to by the > > workspace, brought in by a fetch. Because it's a very common > > operation, especially in synchronizing mirror repos, git pull will > > automatically fetch and merge. Perhaps that what you think about it. > > I know all of the above, and I don't see where it contradicts what I > wrote. You wrote "the meta-data needs to be brought in". That's simply false; when git merge is invoked, the meta data must already be present or you will get an "unknown commit" error. You're trying to argue that a merge (and similarly for commit) is something more than it is. It isn't in git, although it is in bzr and hg, and it's something rather different again from either in Darcs. This is just going to lead to more confusion on the part of those who think git "should" be something different than it is. > The original issue was a claim that a merge (as an operation) is "just > a commit", and I said it's more than that. Sergey (at least as quoted above) wrote "merge commit", so technically it *is* just a commit. But in any case, your "more than that" so far is pure hand-waving, not supported by the actual semantics of "git merge," "git commit," or the commit object. This is more your list than mine, I'm happy to use your terminology. But I refuse to accept "it's more than that" as a definition. > My terminology follows the Git glossary man page, which I think > doesn't agree with the above, at least not 100%. E.g., "commit", > neither as a noun nor as a verb, is not described there as "creating a > commit object". Are you looking at the same glossary entry I am? It says (and I quote in full so there can be no confusion): commit As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits. The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version". Also used as a short hand for commit object. As a verb: The action of storing a new snapshot of the project's state in the Git history, by creating a new commit representing the current state of the index and advancing HEAD to point at the new commit. The "verb" describes exactly "creating a commit object", using the shorthand of "commit" for "commit object" described in the noun section. The additional semantics you pull in are simply not there at all, except in a reference to "same places other VCSes" use different words that is so vague it makes me cringe. Note that you can't even claim that there's a need to collect meta data for the tree; that's *already* in the index in principle (ie, if you use "git add ; git commit" instead of the shorthand "git commit "). You can quibble a bit, for example, you can claim that "git commit " is more fundamental than I claim above. But I don't see much room for anything more than "you may need to create a tree object a well as a commit object." If you want to claim there are additional semantics, I see no alternative except that you define them explicitly, as I requested above.