Jan Hudec <bulb@xxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
