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 07:40:40 +0900 Message-ID: <87384ii26v.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428014478 14118 80.91.229.3 (2 Apr 2015 22:41:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 22:41:18 +0000 (UTC) Cc: Sergey Organov , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 03 00:41:09 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 1YdnnO-00037x-28 for ged-emacs-devel@m.gmane.org; Fri, 03 Apr 2015 00:41:06 +0200 Original-Received: from localhost ([::1]:60353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdnnN-00063J-AA for ged-emacs-devel@m.gmane.org; Thu, 02 Apr 2015 18:41:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdnnA-00063E-QK for emacs-devel@gnu.org; Thu, 02 Apr 2015 18:40:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ydnn9-0007It-Rn for emacs-devel@gnu.org; Thu, 02 Apr 2015 18:40:52 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:57779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydnn3-0007Hn-2B; Thu, 02 Apr 2015 18:40:45 -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 B730C1C38B0; Fri, 3 Apr 2015 07:40:40 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8FEF9120EC9; Fri, 3 Apr 2015 07:40:40 +0900 (JST) In-Reply-To: <831tk2qvz5.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:184808 Archived-At: 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. > You can call all of this a "commit", but then you probably mean > "commit object", a different beast. Using confusing shorts in this > discussion doesn't help understanding. In discussing git, claiming that "commit" is anything other than a verb that means "to create a commit object" is what confuses understanding. You will confuse those who are familiar with git and give incorrect ideas to those who aren't. If you have a different concept of what a commit "should be", you need to explain that, and what sequence of git operations correspond to that concept.