From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup 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 14:21:47 +0100 Message-ID: <87h9l995ec.fsf@fencepost.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> <87ziz213wx.fsf@fencepost.gnu.org> <20151029123554.GB2510@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446124917 15949 80.91.229.3 (29 Oct 2015 13:21:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 13:21:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 14:21:57 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 1Zrn9Q-0001xX-J8 for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 14:21:56 +0100 Original-Received: from localhost ([::1]:44075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrn9P-0003Hz-Na for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 09:21:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrn9K-0003HN-Gu for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:21:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zrn9I-0007n5-IZ for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:21:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrn9I-0007n0-EO; Thu, 29 Oct 2015 09:21:48 -0400 Original-Received: from localhost ([127.0.0.1]:60595 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zrn9H-000513-Q9; Thu, 29 Oct 2015 09:21:48 -0400 Original-Received: by lola (Postfix, from userid 1000) id 73A8BDF96B; Thu, 29 Oct 2015 14:21:47 +0100 (CET) In-Reply-To: <20151029123554.GB2510@acm.fritz.box> (Alan Mackenzie's message of "Thu, 29 Oct 2015 12:35:54 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:192892 Archived-At: Alan Mackenzie writes: > Hello, David. > > On Thu, Oct 29, 2015 at 09:21:02AM +0100, David Kastrup wrote: >> Alan Mackenzie writes: > >> > It wouldn't work well for me. The word "commit" has a meaning, Slowly I am suspecting you are trying hard to make _both_ words in "git commit" have a meaning. Do you also try to make your mouse squeek by removing the oil in its bearings? >> > 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. It is a waste of time trying to teach a computer utility the meaning of English by example. Seriously, get a grip. The meaning of talking to a computer lies in what the computer does in consequence, not in how you say it. You would not write a program in C with array indices starting at 1 just because the mathematical indices start at 1. That you ascribe some particular meaning to "commit" in English common language does not change one iota of what "git commit" does. >> > 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. Sorry, but that's hogwash. Unless you commit everything habitually in a single humongous commit rather than in a sequence if individually reviewable logical steps. In which case you should change your habits for the sake of reviewers and readers. >> 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_, I repeat _not_ listening. I described exactly how you later continue work. You choose to ignore what I wrote in order to make a point of Git using English differently from how you'd want to interpret it. That's nothing short of petulant. >> 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. Part of the "implementation" is structuring your work into usefully reviewable and understandable bits. >> > 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. You certainly can do so with your own repository. It doesn't happen easily, but everything not reachable via branches is cleaned out after a grace period of 3 months. And of course you can speed this up to "right now" in case you committed sensitive data or wagonloads of crud. But even if you don't work with the full-steam cleanup tools, people will have to actually know commit-ids in order to access stuff from your repository that is no longer reachable, at least when they are working with the standard communication channels without direct access to the repository. > Commits actually belong to the repository, which imposes stringent > restrictions upon what can be done with them. You are confused. There is no restriction whatsoever to what you can do to commits in _your_ repository. >> 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. That's why you use git rebase -i and git commit --amend in order to fix your submission before you submit it. > 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. Please learn to work with git rebase -i at the very least, even if you refuse to learn about git commit --amend. Your arguments are ridiculously wrong and based on juggling with words rather than bothering to learn what they mean in the context of working with Git. Take a look at, say, . Do you want to tell me that you get a logical structure of commits like that right at first try, without ever having to go back? Do you think you are doing anybody a favor by dumping work like that in a single commit, even when parts of that commit would have been auto-generated and needed preparatory and conclusive work? >> > 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. So you insist that once you have a silly commit, you do not want to fix it? But rather push it? As a favor to whom? > 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. You rebase. >> > 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. I repeat: if you refuse to learn about git commit --amend as well as git rebase -i, you don't have what it takes to participate in a meaningful discussion about workflows. > 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. You'll find that this comes with its own problems. It has its place (and you'll find the disk space impact pretty tolerable since Git defaults to making hard links between cloned repositories on the same drive), but it's not a one-size-fits all solution. In particular if you are working on several different angles to the same problem, being able to merge, rebase, cherry-pick between approaches is useful and requires your stuff to be in the same repository. > Conceptually, working files are associated with a particular branch, > not the repository as a whole, and git does not handle working files > well. Shrug. man git-worktree should help you. > 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. Again, your insistence of interpreting Git's actions and related workflows solely based on the common English meaning of parts of its command names is plain silly. > The bug it works around is the failure properly to associate working > files with the pertinent branch. At some point of time you should develop a theory as to why Git actually managed to become the most popular version control system in spite of the meaning of its commands not being obvious as soon as you can wave around an English language certificate. -- David Kastrup