Re: Data Integrity & un-Commited Branches

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

Jan Hudec <bulb@ucw.cz> wrote:
> On Fri, Sep 14, 2007 at 22:51:29 -0400, Shawn O. Pearce 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?
> 
> I think it would be reasonable if it just forced you to decide about it. That
> is reading the documentation, checkout only switches branches if the merge of
> each modified file is trivial and only does 3-way merge if it got -m option.
> 
> It might be reasonable to requre that option for all cases, where there are
> local changes and the branches don't point to the same commit and without it,
> checkout should say something like:
> 
>   Cannot switch branches, because the tree is modified. You can apply the
>   modifications to the target branch by using -m option

The thing there is `git checkout` by default does a switch only
if the merge is really trivial.  In such cases its probably sane
to carry the changes with you to the new branch/parent commit.
At worst you can safely carry them right back.  Or stash them.
But -m does a three-way file merge, which isn't trivial, and can
result in conflicts.

So I know that myself and Junio both rely on the default behavior
to tell us if a switch is even a good idea right now, or if we
should stash the changes and *then* do the switch.  Because if you
do the switch with -m and there are conflicts you are up a creek
with no paddle... and there's a mighty big water fall coming up
in 3 feet... 2 feet... oh crap!

Making -m the only way to switch with dirty state is not a feature.
Its a regression.

-- 
Shawn.