From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Git question: when using branches, how does git treat working files when changing branches? Date: Thu, 29 Oct 2015 18:16:46 +0200 Message-ID: <83611p3b0x.fsf@gnu.org> References: <20151028192017.GC2538@acm.fritz.box> <87k2q6wy8p.fsf@linaro.org> <20151028223252.GD2538@acm.fritz.box> <87vb9qd2h4.fsf@wanadoo.es> <20151028235340.GE2538@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1446135535 7214 80.91.229.3 (29 Oct 2015 16:18:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 16:18:55 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 17:18:44 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 1ZrpuU-00004x-9g for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 17:18:42 +0100 Original-Received: from localhost ([::1]:45216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrpuT-0003lV-J6 for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 12:18:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrpuE-0003lQ-5D for emacs-devel@gnu.org; Thu, 29 Oct 2015 12:18:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zrpu9-0005UC-Qr for emacs-devel@gnu.org; Thu, 29 Oct 2015 12:18:26 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:55235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrpu9-0005Tx-ID for emacs-devel@gnu.org; Thu, 29 Oct 2015 12:18:21 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NWZ00100P7THQ00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Thu, 29 Oct 2015 18:16:45 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWZ0011FP7WFC70@a-mtaout21.012.net.il>; Thu, 29 Oct 2015 18:16:44 +0200 (IST) In-reply-to: <20151028235340.GE2538@acm.fritz.box> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:192908 Archived-At: > Date: Wed, 28 Oct 2015 23:53:40 +0000 > From: Alan Mackenzie > Cc: emacs-devel@gnu.org > > > 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. I suggest that you rethink this concept. What you describe makes sense when using centralized VCS, where "commit" goes upstream and is immediately made public; doing this with unfinished work is unwise, of course. But you are using a dVCS, where commits are local until pushed. Moreover, I understand that your entire branch is local, which means none of what you do on that branch is visible to anyone but you. This makes the grave meaning you seem to assign to a commit null and void. In a dVCS, local commits are best used for your own personal tracking of your work, a kind of log that is automagically linked to the code changes you make as you go. Which means, in particular, that you and you alone determine when it's okay to commit, and the commit log messages don't have to make sense to anyone but you. Given all that, committing frequently on such a branch makes a lot of sense, because it lets you track your work with much more fine-grained resolution. An immediate benefit is that you no longer need to depend on your memory to remember when and why you made some change -- you can see it with VCS commands, and you can put into the log messages the rationale that will explain the "why" part. Another significant benefit is that bisecting bugs you find later gives much more precise results, and, with good log messages, it's easy to quickly understand why you made the offending change, and how to test the alternative solution to be sure it doesn't break whatever reason that led you to that change. It goes without saying that even with this workflow, some commits are "more equal" than others. Examples include commits you make after you finish testing some of your code, commits you make after a meaningful part of the feature is done, etc. But it's easy to indicate the significance of these commits in the log messages, so they are later easily identified in the commit log. IOW, you have all the means to support both "meaningful" commits and the less-meaningful ones. The latter kinds could have a log message such as Finished coding FOO, but didn't test it yet. or even Wrote function 'foobar', but didn't try to compile it yet. The messages make it clear these commits are unfinished WIP, but so what? it's your own personal log that it's nobody's business to read. > 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. This issue, if it bothers you, have an easy solution: when you are done with your feature, instead of merging it onto master, _rebase_ it on the master branch using Git's "rebase -i" command. That allows you to squash all your local commits into a single commit on master. (The exact procedure can be found via Google and is described under "Interactive Mode" on the "git rebase" man page; search for "squash" in that description.) FWIW, I'm generally not bothered to have my local commits be visible after I merge the feature branch, so I just use "git merge". But that's me; I know that some people don't like to show their local history, and prefer "rebase". Bottom line, a dVCS gives you some useful new functionalities, and some of that justifies rethinking your old habits, in order to make you work more convenient. I think this is one of them. P.S. I see that David wrote something very similar in spirit.