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: Tue, 31 Mar 2015 15:48:39 +0000 Message-ID: <20150331154839.GE2871@acm.fritz.box> References: <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> <86ego5cp95.fsf@dod.no> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1427816964 6628 80.91.229.3 (31 Mar 2015 15:49:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 15:49:24 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 17:49:08 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 1YcyPZ-00046L-J9 for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 17:49:05 +0200 Original-Received: from localhost ([::1]:39311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcyPZ-0006Ow-0H for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 11:49:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcyPU-0006Op-HY for emacs-devel@gnu.org; Tue, 31 Mar 2015 11:49:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcyPO-0006PD-6i for emacs-devel@gnu.org; Tue, 31 Mar 2015 11:49:00 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:34321 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcyPN-0006Oy-Sy for emacs-devel@gnu.org; Tue, 31 Mar 2015 11:48:54 -0400 Original-Received: (qmail 52229 invoked by uid 3782); 31 Mar 2015 15:48:50 -0000 Original-Received: from acm.muc.de (pD9519B17.dip0.t-ipconnect.de [217.81.155.23]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 31 Mar 2015 17:48:49 +0200 Original-Received: (qmail 5622 invoked by uid 1000); 31 Mar 2015 15:48:39 -0000 Content-Disposition: inline In-Reply-To: <86ego5cp95.fsf@dod.no> 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:184650 Archived-At: Hello, Steinar. On Tue, Mar 31, 2015 at 02:42:14PM +0200, Steinar Bang wrote: > >>>>> 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. I've never used git reset or a git --force argument. I did lose some changes, however. > > 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). That's a fix? So every time I want to do a pull I have to stash, pull, unstash. Yuck! A proper fix would be for merge to actually merge the new changes into the working directory. > 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...). Not me. In my normal workflow, I commit at the last minute, then push. Just before committing, I get the latest changes from savannah, do any necessary merging, then commit and push as quickly as possible. This is to minimise the hassle which invariably occurs when other people's commits get mixed up with my own. Is it really too much to expect that git merge should merge these new fetched changes into my working directory? > In short: it can be difficult to know what changes belongs to the merge > and what were local uncommitted changes prior to the merge. I don't know what you mean by "the" merge. When one mixes up committing with staging with fetching with pushing, inevitably there will sometimes be merge operations required all over the place. > One heuristic could be that the unconflicted uncommitted changes don't > belong to the merge, ... Sorry, this is ceasing to make sense to me. I can't visualise what you're trying to say. When there are uncommitted changes and some merge takes place at a place where these changes are, the changes can't avoid being part of that 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. I think I'm OK with the fetch part. It's the merge part I have difficulties with. > > 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 It may be quite good, but it's information density is very low. It's written for beginners in VCS. Every time I read, yet again, that VCSs have the concept of a branch and what it's used for, my eyes glaze over, and I start subconsciously skimming the text in the hope of coming across something solid and useful. The information density in the git-merge man page is low in a different way: being so vague and imprecise it makes little sense on its own, because you've got to keep searching externally for information needed to get meaning out of it. -- Alan Mackenzie (Nuremberg, Germany).