Re: Git question: when using branches, how does git treat working files when changing branches?

[Alan Mackenzie]

Hello, David.

On Thu, Oct 29, 2015 at 09:21:02AM +0100, David Kastrup wrote:
> Alan Mackenzie <address@hidden> 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).