On Thu, 14 Jun 2007, Bill Lear wrote: > On Wednesday, June 13, 2007 at 22:21:38 (-0700) Linus Torvalds writes: > >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 have now officially fallen out of my chair. Well, the thing is, I actually pull into dirty trees all the time. So I can really see the point of wanting to have some dirty state (you're not ready to commit it yet), but still wanting to update your tree to some newer state.. Of course, in the kernel (where I do this - I do it to a much lesser degree in git too, but for the kernel it's "normal" for me to do it), we have very good modularization of source code, so I can do the "pull into a dirty tree" with _current_ git, just because there is almost never a clash (and if there is, nothing bad happens: the pull won't succeed, and I can decide to either stash away my diff or just undo it, and then re-pull afterwards). But I can also well imagine that other projects aren't quite as modular as the kernel is. In fact, I pretty much know that for a fact.. We've spent years splitting things up, just because clashes are nasty. So I don't think the "pull into a dirty tree" is necessarily a horribly bad workflow. It *can* be due to bad habits, but it can equally well be due to perfectly fine habits like having added some debugging code that you actually want to eventually throw away, but you haven't quite debugged it totally yet. For example, maybe the reason you pull is because there's a potential fix in upstream - you want to keep your debugging code (to _verify_ the fix, or verify that it wasn't a fix at all). The fact that some CVS users do it because they are used to it doesn't _automatically_ make it bad form. They probably have really bad reasons for doing it (namely the fact that under CVS, you cannot commit to your tree as aggressively as you can under git, since committing affects everybody else too), and *those* reasons may not be true under git, but the other ones (see above) are still what appear to be valid reasons for allowing this.. So the only reason I'm ambivalent is actually that I suspect it's just hard to do cleanly. For example, doing it for the fast-forward case is much easier, but then people will start *wanting* to do it for the more complex "real merge" case, and will complain when that doesn't work. And that one really _is_ fundamentally harder. So it might be easier to take a "git stash ; git pull ; git unstash" approach instead of making "git pull" handle working tree conflicts itseld. 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
