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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 29 Oct 2015 12:35:54 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> 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.

It is meaningful to you.  If you don't want anyone else to see such
log messages, you can squash these commits during the final rebase.

> > No.  No, no, no.  Absolutely no.  The commits in a distributed version
> > control system are yours only.
> 
> They aren't.

The commits you make on your local branch are _only_ yours, and no one
else's.

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

But "git rebase -i" and similar features allow you to rewrite history
when merging to a public branch, if you so wish.

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

That's your prerogative, of course, but you should know that by doing
so you make your life more inconvenient than it could have been.