Re: git pull for update of netdev fails.

[Linus Torvalds <torvalds@osdl.org>]

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