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: Thu, 29 Oct 2015 12:35:54 +0000 Message-ID: <20151029123554.GB2510@acm.fritz.box> References: <20151028192017.GC2538@acm.fritz.box> <87k2q6wy8p.fsf@linaro.org> <20151028223252.GD2538@acm.fritz.box> <87vb9qd2h4.fsf@wanadoo.es> <20151028235340.GE2538@acm.fritz.box> <87ziz213wx.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446122070 32697 80.91.229.3 (29 Oct 2015 12:34:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 12:34:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 13:34:21 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 1ZrmPK-0006TE-KY for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 13:34:18 +0100 Original-Received: from localhost ([::1]:43811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrmPJ-0002EW-RB for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 08:34:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrmPF-0002ED-Km for emacs-devel@gnu.org; Thu, 29 Oct 2015 08:34:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrmPC-0003FG-Bg for emacs-devel@gnu.org; Thu, 29 Oct 2015 08:34:13 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:40398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrmPC-0003F8-1z for emacs-devel@gnu.org; Thu, 29 Oct 2015 08:34:10 -0400 Original-Received: (qmail 61948 invoked by uid 3782); 29 Oct 2015 12:34:09 -0000 Original-Received: from acm.muc.de (p548A58AB.dip0.t-ipconnect.de [84.138.88.171]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 29 Oct 2015 13:34:08 +0100 Original-Received: (qmail 3004 invoked by uid 1000); 29 Oct 2015 12:35:54 -0000 Content-Disposition: inline In-Reply-To: <87ziz213wx.fsf@fencepost.gnu.org> 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:192884 Archived-At: Hello, David. On Thu, Oct 29, 2015 at 09:21:02AM +0100, David Kastrup wrote: > Alan Mackenzie writes: [ .... ] > > 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. > It most certainly would not have told you since a checkout does not > magically stash things. More likely you forget the "list" part and > typed just > git stash > or a variation thereof. I think it's quite likely I did. I can't remember any more. Apologies for stirring things up. > > 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. > Nope, that's what git commit -s is for (Signed-off-by: footer). I was talking about the English word, not the use git makes of it. > > What "commit" _doesn't_ mean is "temporarily store because there's > > nowhere better". > You are working with a distributed version control system. It means > exactly that since you are working with your _private_ repository. > Anything non-trivial I push has actually seen a number of git commit > --amend and git rebase -i reorganizations so that what I end up pushing > is _polished_. It would be equally polished if you simply committed it when it was ready. git commit --amend, and friends, don't polish code. > The most important tool of the mathematician and programmer is the > wastebasket, the most important tool of a distributed version control > system is local commits. A commit should have a meaning. A repository filled up with commit messages like "Commit necessitated by git before switching branches." is not going to make thrilling reading at a later date. > You are not understanding your tool if you insist on using it like CVS, > and you are making life harder for yourself (since you need to get > everything right the first try) and everybody else (since you won't get > everything right the first try). Whether one commits after every single character change, or once when work is completed, or anything in between, the quality of the work depends only on the skill deployed in its implementation and the conscientiousness of its testing. > > 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. > No. No, no, no. Absolutely no. The commits in a distributed version > control system are yours only. They aren't. If they were mine, I could chose to expunge an arbitrary commit from the repository, clearing both file content and the log of dross. Commits actually belong to the repository, which imposes stringent restrictions upon what can be done with them. > It isn't an abuse of the creative process to make your first written > pages match the last written pages as if you exactly knew which words > you were going to write. > The sequence of commits is supposed to tell a story, not be a witness to > how you came up with the story. > Nobody wants to buy a book where the author handed in his wastebasket as > part of the manuscript. Nobody wants to buy a novel where "I woke up at 6:30, had a shower, got shaved, got dressed, had breakfast then went to work." appears three times in every chapter. Similarly, if I'm examining a git repository log, I don't want to have to ignore dross like "Commit necessitated by git ...." messages. A commit should mean something. > > Committed software and work in progress are two different categories > > of code. To confuse them must lead to trouble. > Commits are work in progress up to the point they are signed off on and > pushed to a central repository or offered to the public in some other > way. Even then, review processes might very well change the sequence of > commits into something more sensible before they get accepted into > something less ephemeral than a review branch. Yes. > > 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. > So read the stuff before pushing it upstream. That's just common sense. I've pushed silly commits upstream before. Commits like merges in my own repository. There might be ways of avoiding these, but none of the documentation I've read has made it obvious how. > > 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. > Why would you cancel a commit? That does not make sense. I would want to cancel a "Commit necessitated by git before changing branches" type commit so as not to fill up the repository with dross. Like I said last night, I think I'm just going to use several repositories, each cloned from my main master, rather than several branches within one repository. After all, I have a Terabyte of disk space. Conceptually, working files are associated with a particular branch, not the repository as a whole, and git does not handle working files well. I doubt any other VCS handles them any better. (Is this what Michael Jackson, an author of a structured programming book, used to call a "structure clash"?) Committing working files in an arbitrary state in order to swap branches is a workaround, not a feature. The bug it works around is the failure properly to associate working files with the pertinent branch. > -- > David Kastrup -- Alan Mackenzie (Nuremberg, Germany).