From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Wed, 1 Apr 2015 10:32:25 +0000 Message-ID: <20150401103225.GA2633@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1427884392 13100 80.91.229.3 (1 Apr 2015 10:33:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2015 10:33:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Sergey Organov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 01 12:32:59 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 1YdFxB-00026P-8R for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 12:32:57 +0200 Original-Received: from localhost ([::1]:50069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFxA-0003Xs-Ky for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 06:32:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFwx-0003GA-BP for emacs-devel@gnu.org; Wed, 01 Apr 2015 06:32:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdFwu-000298-Jm for emacs-devel@gnu.org; Wed, 01 Apr 2015 06:32:43 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61267 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFwu-00028g-9P for emacs-devel@gnu.org; Wed, 01 Apr 2015 06:32:40 -0400 Original-Received: (qmail 53852 invoked by uid 3782); 1 Apr 2015 10:32:36 -0000 Original-Received: from acm.muc.de (pD951AF7A.dip0.t-ipconnect.de [217.81.175.122]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Apr 2015 12:32:35 +0200 Original-Received: (qmail 3140 invoked by uid 1000); 1 Apr 2015 10:32:25 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.1 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:184703 Archived-At: Hello, Sergey. On Wed, Apr 01, 2015 at 12:28:25PM +0300, Sergey Organov wrote: > Alan Mackenzie writes: > >> > Part of the problem is that the git-merge man page doesn't say that > >> > it messes with the working tree > >> What else would it do? Merge tools have changed the working tree from > >> time immemorial. > > That's poor, Stephen. It might well merge in the repository without > > touching the working tree. The fact is, the documentation doesn't say > > this - it doesn't even say where the two sources for its merge come from, > > or where it puts the result. > That's pure insinuation. Git documentation could be far from ideal, but > it has most of information there. Here is quote from Git manual page on > merge for you. It mentions what merge does to working tree 4 times, and > tells you exactly where it puts the two sources of conflicting merges: Exaggeration rather than insinuation, I think you mean. The git documentation is very bad. The information may be there, but if it is buried deep down in the small print, it is not useful. We're not talking about arcane details here, we're talking about the basic functionality - what git merge actually does - what does it merge and where does it put the result? It's worth saying that the excerpt you quote below is at approximately line 170 inside the man page. If this is typical of git man pages, then it would seem I have to read, say, ~200 lines of each of 20 or 30 man pages to find the basic functionality of each command. > [QUOTE=git help merge] > TRUE MERGE > Except in a fast-forward merge (see above), the branches to be merged > must be tied together by a merge commit that has both of them as its > parents. > A merged version reconciling the changes from all branches to be merged > is committed, and your HEAD, index, and working tree are updated to it. > It is possible to have modifications in the working tree as long as > they do not overlap; the update will preserve them. > When it is not obvious how to reconcile the changes, the following > happens: > 1. The HEAD pointer stays the same. > 2. The MERGE_HEAD ref is set to point to the other branch head. > 3. Paths that merged cleanly are updated both in the index file and in > your working tree. > 4. For conflicting paths, the index file records up to three versions: > stage 1 stores the version from the common ancestor, stage 2 from > HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with > git ls-files -u). The working tree files contain the result of the > "merge" program; i.e. 3-way merge results with familiar conflict > markers <<< === >>>. > 5. No other changes are made. In particular, the local modifications > you had before you started merge will stay the same and the index > entries for them stay as they were, i.e. matching HEAD. > If you tried a merge which resulted in complex conflicts and want to > start over, you can recover with git merge --abort. > [/QUOTE] > P.S. You sound like pure Git hater most of times. Haters will hate. > No matter what. That's an uncalled for ad hominem. I could equally well call you a git lover, somebody who will love git to the end, deliberately remaining oblivious to its many problems. I do not hate, full stop. I dislike git strongly because it has cost me and continues to cost me an inordinate amount of time and effort to learn and use. The vagueness and general badness of its documentation is a large part of this. > -- Sergey. -- Alan Mackenzie (Nuremberg, Germany).