Re: Data Integrity & un-Commited Branches

["Shawn O. Pearce" <spearce@spearce.org>]

Brian Scott Dobrovodsky <brian@pontech.com> wrote:
> > It isn't unreasonable to want Git to save uncommitted work for the
> > current branch and then you switch to another, ending up with a
> > clean working directory when you finally get there.  Today we have
> > git-stash to help you with this, but I'm thinking maybe we want to
> > connect git-checkout with it?
> 
> That would be great as a default action when using checkout!

Well, a lot of "Git old timers" like the current action of keeping
the tree dirty during a switch.  But maybe we could also teach `git
checkout` that a user specified configuration option can cause it
to automatically stash/unstash unless -m is supplied.  Or something.

Patches are always welcome.  ;-)

> +Switching branches without having to commit improves work flow.
> +Fewer commits = cleaner logs.

Well, I'm not sure that matters here.  Typically Git users will make
heavy use of commit rewriting features (e.g. `git commit --amend`
or `git rebase -i`) to cleanup changes on a side branch before they
submit them to the mainline.  This makes it easy to commit all of
the time and not worry about how the resulting logs will look.
Plus they can have look like they have some serious code-fu and
always write things perfectly the first time. :)

Indeed, before git-stash came about I parked changes on a branch
using the following technique:

	$ git commit -a -m PARK       ; # stash on "demo"
	$ git checkout master         ; # tree is now clean
	$ git checkout demo           ; # back on demo
	$ git reset --soft HEAD^      ; # undo the stash

No messy history, nice neat per-branch stash.  Oh, you can do that
in Git 1.3.  And even earlier probably.  I actually still use this
trick from time to time as I find it flowing out of my fingers far
easier than git-stash.

-- 
Shawn.