Re: pull into dirty working tree

On Wed, 13 Jun 2007, Bill Lear wrote:

We have some CVS users who complain that they cannot do a pull
into a dirty working tree, as they could under CVS.

Well, a lot of people have told you that the answer is "don't do that", 
but I actually somewhat disagree.

I think it might be perfectly fine to allow for a *fast-forward* pull to 
do a three-way merge on the working tree, assuming the index is clean in 
the paths that got modified.

For a real merge (not just a fast-forward), we really *really* must not do 
it, for a very simple reason: we have no sane way to handle conflicts if 
we have both a merge from the pull itself _and_ a merge from the working 
tree. Don't get me wrong: I'm sure it's possible in theory, I just think 
that in practice it's such a total hairball that it's not worth it!

So I think we could actually try to allow "git pull" with a fast-forward 
pull and a dirty working tree.

(We obviously _already_ allow a working tree that is dirty in the paths 
that don't actually get changed at all! I use that all the time. So this 
is strictly limited to the "dirty state actually overlaps with what got 
pulled!)

It might make it a bit easier for CVS people to get used to the git model: 
keep your dirty working tree, and do "git pull" to update it, and fix up 
any conflicts in the working tree. That's how CVS works - it's a bad 
model, but it's a model that may be worth supporting just to get people 
more easily into the _good_ model.

		Linus