From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sergey Organov Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Wed, 01 Apr 2015 18:52:20 +0300 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1427903579 1086 80.91.229.3 (1 Apr 2015 15:52:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2015 15:52:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 01 17:52:51 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 1YdKwk-00022f-RA for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 17:52:50 +0200 Original-Received: from localhost ([::1]:53572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdKwk-0002B6-9N for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2015 11:52:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdKwg-0002B1-1E for emacs-devel@gnu.org; Wed, 01 Apr 2015 11:52:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdKwb-0006Cb-Vs for emacs-devel@gnu.org; Wed, 01 Apr 2015 11:52:45 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:34860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdKwb-0006CS-Oz for emacs-devel@gnu.org; Wed, 01 Apr 2015 11:52:41 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YdKwa-0001wJ-El for emacs-devel@gnu.org; Wed, 01 Apr 2015 17:52:40 +0200 Original-Received: from 89.175.180.246 ([89.175.180.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Apr 2015 17:52:40 +0200 Original-Received: from sorganov by 89.175.180.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Apr 2015 17:52:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 81 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89.175.180.246 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:184735 Archived-At: Eli Zaretskii writes: >> From: Sergey Organov >> Date: Wed, 01 Apr 2015 16:03:26 +0300 >> Cc: emacs-devel@gnu.org >> >> > Exaggeration rather than insinuation, I think you mean. >> >> I said what I meant: insinuation. > > I think you were wrong. > >> If you are not interested in details, the manual page explains what >> merge does and where it puts result in the first sentence of the >> description: >> >> "Incorporates changes from the named commits (since the time their >> histories diverged from the current branch) into the current branch." > > Good luck understanding this when learning what merge does in Git! > Starting from the "branch" thingy, which, as you will read everywhere > is just a pointer to the HEAD commit. So what does it mean to > "incorporate changes in the current branch", if the branch is just a > pointer? Yes, a pointer that moves to point to new commit automatically every time you commit on the branch. Incorporating changes means the same thing every time: commit. What's new or unusual about it? > And then there's "histories diverged" part, of course, that is never > explained. Yeah it's total mystery to everybody. If one is so novice that she has no idea about "history diverged" thingy, she should really start from some basic tutorial, not from reading "git merge" manual page. > And finally, even if you succeed in negotiating these obstacles, > there's still the important question: what does it mean to > "incorporate in the branch"? what does it change, and in what order? Basically, it means exactly what it says: your changes from divergence point to the named commit will now be there in the current branch. The details are explained later in the same manual page, as they depend on different modes of operation. > Of course, if you already know how merge works in Git, have merged > your own branches several times, and had your share of mistakes until > you finally got it -- then this text will speak volumes to you. But > that's not what Alan complained about. In this particular case he said utter lie about particular git manual page. It's useless to deny that. That was the only reason I had to intervene. >> >> > Part of the problem is that the git-merge man page doesn't say that >> >> > it messes with the working tree >> >> Oh, really? Anybody who doesn't actively avoid to understand anything >> "git" will easily infer that the working tree should be updated >> accordingly, as "the current" is those branch that working tree >> reflects, by definition. > > Oh, really? You mean merge doesn't work, or is a no-op, in a "bare" > repository, where there's no tree? [(BARE:master)]$ git merge v3.6 fatal: This operation must be run in a work tree [(BARE:master)]$ But it's even irrelevant. One needs to have work tree to care about changes to work tree, that excludes bare repositories from discussion. > Give up! Git's documentation "needs work" (TM). It's futile to try > to refute that. Nobody refutes it. Any documentation needs work (TM). Git's needs work. It does not mean that spreading misinformation about its current state is acceptable. -- Sergey.