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