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

[David Kastrup]

Alan Mackenzie <address@hidden> writes:

> Hello, Óscar.
>
> On Wed, Oct 28, 2015 at 11:59:03PM +0100, Óscar Fuentes wrote:
>> Alan Mackenzie <address@hidden> 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:
>
>> address@hidden:~/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.

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.

> 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).

> 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_.

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.

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).

> 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.  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.

> 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.

> 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.

> 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.

> git hid my changes, for what reason I don't know.

If your shell has a history command, I'm pretty sure that there will be
an explicit hint about why "git" "hid" your changes.

-- 
David Kastrup