On Wed, 20 Sep 2006, Shawn Pearce wrote: > > > > This is not just a random thing. It is in fact one of the very core issues > > of having multiple people work together on the same remote repo. We don't > > do it very much (because it's often easier for everybody to have their > > own), but the "CVS workflow" with one common repository is another example > > why WE MUST NOT JUST RESET THE HEADS! > > BTW `git push --force` works just great to reset the remote head. Yes. That's why "--force" exists - it's a way of saying "the other end is wrong, and I really do want to force this update". > I worked on a project not to long ago in which a user tried `git > push`, received a "not a fast-forward" error, didn't know what it > meant, tried `git push --force`, found that worked, and proceeded > to force every push he did from then on. To much gnashing of teeth > from everyone else. Ouch. That implies that we made it a bit too easy to force things, or that we have an insufficiently clear error message. I think the current error message is fairly good: it says "remote '%s' is not a strict subset of local ref '%s'. maybe you are not up-to-date and need to pull first?" which should be clear enough, but I'm hoping this was a long time ago when we weren't as clear (we added the "maybe you're not up-to-date .." language later) > Of course an update hook finally took care of the problem, but having > non fast-forward pushs be permitted on a shared, bare repository > by default is interesting to say the least. :-) Yeah, well, it's not permitted "by default", but obviously "--force" ends up being a client-side decision, so with clueless clients, the default behaviour may not be enough to save you. 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