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

[Davis Herring]

> It wouldn't work well for me.  The word "commit" has a meaning,
> something like "hand over on a permanent basis".

And, with a limited scope, that's what "git commit" does: hands over
your code (actually the "index" or "staging area") to the repository
permanently (unless/until countermanded, of course).  That the
destination is "your repository" rather than "the Emacs central
repository" does not prevent its being a commit, but it does (as has
been discussed to death elsewhere on this thread) change the social
implications of the commit drastically.

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

If you want, maintain (local) branches named things like "eligible" and
"scratch" (perhaps such a pair per logical change you're working on).
You can then feel free to commit regardless of quality to scratch,
knowing that you would never push such a branch.  That frees your
attention to switch branches.  When you come back, you can rebase/amend
the scratch commit(s) as needed, then put them onto eligible.  It's a
separate question of when "eligible" is complete enough to be worth
pushing to a public location.

The change (for any given piece of work) from scratch to eligible is
then a question of quality, whereas from eligible to Savannah is a
question of completeness.  It's all reasonably self-explanatory once you
choose your names.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.