On Fri, 16 Oct 2009, Julian Phillips wrote: > It was the approach that I was trying to suggest rather than the actual > commands. The point I was trying to make was how, as a user, I would be happy > to git behave. > > So, I try to run fetch, git says "ooh, now that would be dangerous - you can > force it happen by running "git foo", but you will then be in situation X, > which you can then recover from by running "git bar", though you may need to > run "git stash" to save any edits you have made" or something similar. > > Now as a user I know that I have tried to do something a bit unusual, but I > don't have to run to the mailing list or #git saying "I just did X Y Z and > everything is now FUBARed". I can even proceed to do the unusal thing, as git > itself has given me the information I need to sort things out afterwards. The thing is that that sequence shouldn't be unusual or dangerous or require sorting things out afterwards. In the current version of git, it's a completely normal thing to do that behaves nicely and does what the user almost certainly wants. We *could* horribly break it, and then add messages to tell the user they're doing something that's now horribly broken, and tell the user how to cope with the fact that what they want to do involves something that's horribly broken, and roll our eyes when users who have only used working systems like SVN or git 1.6.X ignore the message and can't figure out what's going on. Or we could just not break it in the first place. SVN doesn't think that your working directory is supposed to change when someone else makes a commit. Git shouldn't think your working directory should change when you find out that someone made a commit. If you want to see now commits, you do "svn up" or "git checkout". -Daniel *This .sig left intentionally blank* -- 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