From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Tue, 31 Mar 2015 14:42:14 +0200 Organization: Probably a good idea Message-ID: <86ego5cp95.fsf@dod.no> 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 X-Trace: ger.gmane.org 1427805768 1403 80.91.229.3 (31 Mar 2015 12:42:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 12:42:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 14:42:39 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 1YcvV6-0000yw-BY for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 14:42:36 +0200 Original-Received: from localhost ([::1]:38541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcvV5-0008Vf-Lz for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 08:42:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcvUr-0008VO-EL for emacs-devel@gnu.org; Tue, 31 Mar 2015 08:42:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcvUo-0006ik-79 for emacs-devel@gnu.org; Tue, 31 Mar 2015 08:42:21 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:39945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcvUn-0006ig-WC for emacs-devel@gnu.org; Tue, 31 Mar 2015 08:42:18 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YcvUc-0000bA-1C for emacs-devel@gnu.org; Tue, 31 Mar 2015 14:42:06 +0200 Original-Received: from cm-84.208.248.210.getinternet.no ([84.208.248.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 14:42:05 +0200 Original-Received: from sb by cm-84.208.248.210.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 14:42:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 52 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.208.248.210.getinternet.no Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (windows-nt) Cancel-Lock: sha1:3kDBIA/6DP1LMZ73I1331e13c7I= 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:184613 Archived-At: >>>>> Alan Mackenzie : > I lost some changes in my working directory after doing something like > git pull. I can't remember the details any more. I was able to > reconstruct the changes without too much difficulty. I've have *never* had git overwrite my changes except using "git reset --hard" or any of the "--force" arguments. > 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. Their fix is to ask you to commit (or stash) before you pull (which is fetch followed by merge). If the commits stops because if something, you will have a workspace with some staged files, some unstaged files holding conflicted files, and some unstaged files holding your uncommitted changes (potentially there could be staged files unrelated to the merge as well, but anyone knowing how to stage files have probably committed before the pull...). In short: it can be difficult to know what changes belongs to the merge and what were local uncommitted changes prior to the merge. One heuristic could be that the unconflicted uncommitted changes don't belong to the merge, but it if was that simple I suspect that this would already be the case. > 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. > 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. FWIW git completes the fetch before doing the merge, so all the upstream changes are present and can be manually merged. > Part of the problem is that the git-merge man page doesn't say that it > messes with the working tree (or, more precisely, it vaguely alludes to > it in the small print several hundred pages down). In fact, it doesn't > say up front _what_ it is merging, or where the merged result goes - it > merely says "Join two or more development histories together", leaving it > as an exercise for the reader to figure out exactly what is meant by a > "development history". This chapter of "Pro Git", is quite good: http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell