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: Tue, 31 Mar 2015 23:02:16 +0900 Message-ID: <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <871tk6538w.fsf@gnu.org> <838ueezgyk.fsf@gnu.org> <878ueejnjz.fsf@uwakimon.sk.tsukuba.ac.jp> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1427810581 21114 80.91.229.3 (31 Mar 2015 14:03:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 14:03:01 +0000 (UTC) Cc: Andreas Schwab , Harald Hanche-Olsen , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 16:02:41 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 1YcwkU-0003bK-4Q for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 16:02:34 +0200 Original-Received: from localhost ([::1]:38816 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcwkT-0002Fg-GA for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 10:02:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcwkL-00029P-AM for emacs-devel@gnu.org; Tue, 31 Mar 2015 10:02:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcwkG-0002xN-1H for emacs-devel@gnu.org; Tue, 31 Mar 2015 10:02:25 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:50340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcwkF-0002wp-OK; Tue, 31 Mar 2015 10:02:19 -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 5915F1C38EA; Tue, 31 Mar 2015 23:02:16 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 31ECC120EC9; Tue, 31 Mar 2015 23:02:16 +0900 (JST) In-Reply-To: <20150331104935.GB2871@acm.fritz.box> 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:184625 Archived-At: Alan Mackenzie writes: > I lost some changes in my working directory after doing something > like git pull. I can't remember the details any more. "Something like." "Can't remember." That's the real problem, and git (or whatever the VCS in use is, but for Emacs it's git) is the solution. "Commit early, commit often", and you won't have to worry about remembering the details of your workflow. > I was able to reconstruct the changes without too much difficulty. That's good. But people aren't always that lucky. > > It does, the same way that bzr or Mercurial does.[1] I don't see > > why you would think otherwise. > > Partly due to the following bug report which is near the start of the > git-merge man page: "Warning: Running git merge with non-trivial > uncommitted changes is discouraged: while possible, it may leave you in a > state that is hard to back out of in the case of a conflict.". I can't > imagine why the git maintainers don't fix this. Fix what? One can do it if one wants to. It's usually not dangerous because merge will abort if there are any local uncommitted changes in a file that would be changed by the merge. It's actually rather useful in certain limited use cases, for example when I have a different ignore file from upstream. In Mercurial, I have a patch in a queue that handles this but it's PITA to deal with. (Note that everybody's favorite blunted plastic scissors, aka Bazaar, has a "merge --force" option to allow the user to make the choice.) It is indeed a bad idea to do a lot of work without committing and then merging. But that's a trivial deduction from the general theorem: it is a bad idea to do a lot of work without committing. > With git pull, if there are changes in the working directory, the merge > (i.e. merge from remote/master into master) part of the operation is > aborted before it starts, giving a message describing its refusal. It > does this even when there are no conflicts to deal with. No, it only does it if a locally changed file is to be updated by the merge. That is a conflict, because git has no way to bring you back to the current state if you want to come back. Git only knows how to bring you back to a state that was committed. > Mercurial will complete hg pull regardless of any changes in its working > directory; in the case of conflicts it may leave several heads which > require merging. Which is exactly what git does: b 22:00$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /tmp/test/./a 684eca7..d47c24c master -> origin/master <<<< LOOK LOOK LOOK Updating 684eca7..d47c24c error: Your local changes to the following files would be overwritten by merge: quuz Please, commit your changes or stash them before you can merge. Aborting I think you're partly confused by the fact that what Mercurial calls pull is what git calls fetch, and what git calls pull has no equivalent in core Mercurial AFAIK (pull -u only updates on a fast forward). > 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. What's different from traditional 3-way merge tools (that aren't part of a VCS) is that git *also* creates a commit with more than one parent (which is what is meant by joining development histories). I find it a PITA that Mercurial doesn't, but rather requires a separate merge operation and then an explicit commit. > By contrast, hg merge is documented concisely and adequately as > "merge another revision into working directory". Everybody hates git's documentation. I thought you were complaining about bugs in the program?