Re: pull into dirty working tree

On Wed, 13 Jun 2007, Bill Lear wrote:

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