Re: Data Integrity & un-Commited Branches

From: Shawn O. Pearce <spearce@spearce.org>
Date: Sep 15, 2007, 07:51 UTC
Message-ID: <20070915075144.GB3099@spearce.org>
In-Reply-To: <20070915073845.GB3782@efreet.light.src>

Jan Hudec <bulb@ucw.cz> wrote:

Show 17 quoted lines

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