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: Git question: when using branches, how does git treat working files when changing branches? Date: Wed, 28 Oct 2015 23:53:40 +0000 Message-ID: <20151028235340.GE2538@acm.fritz.box> References: <20151028192017.GC2538@acm.fritz.box> <87k2q6wy8p.fsf@linaro.org> <20151028223252.GD2538@acm.fritz.box> <87vb9qd2h4.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1446076351 21252 80.91.229.3 (28 Oct 2015 23:52:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Oct 2015 23:52:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 00:52:16 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 1ZraVq-0005Ev-7t for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 00:52:14 +0100 Original-Received: from localhost ([::1]:41158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZraVp-0001Ik-OP for ged-emacs-devel@m.gmane.org; Wed, 28 Oct 2015 19:52:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZraVd-0001Ie-Ds for emacs-devel@gnu.org; Wed, 28 Oct 2015 19:52:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZraVa-0005wp-6y for emacs-devel@gnu.org; Wed, 28 Oct 2015 19:52:01 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:18938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZraVZ-0005wQ-QI for emacs-devel@gnu.org; Wed, 28 Oct 2015 19:51:58 -0400 Original-Received: (qmail 96284 invoked by uid 3782); 28 Oct 2015 23:51:55 -0000 Original-Received: from acm.muc.de (p579E8681.dip0.t-ipconnect.de [87.158.134.129]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 29 Oct 2015 00:51:54 +0100 Original-Received: (qmail 14545 invoked by uid 1000); 28 Oct 2015 23:53:40 -0000 Content-Disposition: inline In-Reply-To: <87vb9qd2h4.fsf@wanadoo.es> 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.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:192836 Archived-At: Hello, Óscar. On Wed, Oct 28, 2015 at 11:59:03PM +0100, Óscar Fuentes wrote: > Alan Mackenzie writes: > Joining the emacs-devel git hot line... > >> By default git will complain if changing branches would revert > >> uncommitted changes. > > OK, I started with a test repository, with some changes in (which I saved > > in a diff file). After listing the available branches, and chosing one > > at random, I did > > $ git checkout /origin/master > > , and got some message or other about a detached head. Without doing > > anything else I then switched back with > > $ git checkout master. > > git status now reports that the working directory is "clean". So one of > > these two operations has discarded my changes. > This is hard to believe, so I tried your steps: > oscar@qcore:~/dev/emacs/emacs$ git checkout /origin/master > fatal: Could not switch to '/origin/': No such file or directory > As you can see, your first command fails to complete. I requested this > on a previous question of yours about git and I request it again: please > post the *exact* commands and its output. Otherwise, claims like what > you made above are dubious, at best. As you probably could guess, "/origin/master" was a typo, and the actual text was "origin/master". It's getting quite late. Having a look at my series of commands after the first git checkout, I in fact did a git stash list. I don't think that list was empty when I typed that command. It isn't empty now. In other words, that first git checkout stashed my changes, it didn't discard them. It may have told me, it might not have. > [snip] > >> Well I usually do a stash/rebase/stash-pop cycle in magit. However you > >> may want to look at the rebase.autostash option (since Git 2.6) > > The problem is that, according to David K, there's only one stash stack, > > so it would be very inconvenient having to keep track of which entries in > > this stack belong to which branches. > David Kastrup also suggested to commit your changes before switching > branches, I wonder why you ignored his advice. It wouldn't work well for me. The word "commit" has a meaning, something like "hand over on a permanent basis". When you make a "commitment", you are pledging your honour that you will stand behind what you have committed. What "commit" _doesn't_ mean is "temporarily store because there's nowhere better". Of course there are ways of undoing a commit if it was done by mistake. But routinely to commit to something with the intention of repudiating it later is an abuse. It is the sort of thing politicians do. Committed software and work in progress are two different categories of code. To confuse them must lead to trouble. If I were were to commit unfinished changes just for lack of somewhere proper to store them, inevitably some of these changes would find themselves becoming permanent, embarassingly so. Having continually to remember to cancel a commit each time I change branches would be an extra level of stress, of which there is already enough with git. > Over the years I used several VC systems (CVS and subversion, among > others) and git is, by far, the one that makes things easier when you > don't want to lose your changes, committed or not. git hid my changes, for what reason I don't know. Right at the moment, 00:41 (which isn't a good time to make judgements), I don't think I'm going to be using these branches, they're just to awkward for the way I work. Instead I'll use several distinct repositories, minimising the potential for confusion and loss. I'll need a more intelligent backup strategy than I've got at the moment, but I can manage that. > Finally, I wholeheartedly recommend to give Magit a try. Sometime, maybe. Trouble is, it's all more stuff to learn, and it might not work well for me. > [snip] -- Alan Mackenzie (Nuremberg, Germany).