Re: git pull for update of netdev fails.

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 20, 2006, 16:49 UTC
Message-ID: <Pine.LNX.4.64.0609200942550.4388@g5.osdl.org>
In-Reply-To: <20060920163437.GC23260@spearce.org>

On Wed, 20 Sep 2006, Shawn Pearce wrote:

Show 8 quoted lines

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

Show 5 quoted lines

> 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