Re: git pull for update of netdev fails.

[Shawn Pearce <spearce@spearce.org>]

Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
> > 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've been lucky that I've only run into two people in my life that
when faced with an error message they don't understand immediately
try adding "-f" and "--force" to the command line until something
happens.  Its entertaining to read their terminal scrollback and
see what they did in response to errors; its less so when they've
done mildy destructive things that you now must cleanup.

Sometimes I wonder if they've managed to reformat their root
filesystem while they had it mounted.  Never asked.  Not sure I
want to hear the answer.
 
> 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)

Yes; this problem was back with Git 1.2 so the newer language is
much better and should help new users better.
 
> > 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.

I'm wondering if maybe git-receive-pack should deny forcing an
update in a shared repository unless there's either an update hook
that its going to run (which would get to vote yea or neigh) or
there's a configuration setting enabled which isn't set by default.

I'd think most users of a shared repository wouldn't want to allow
forcing an update except in some very special cases.  For those
they could install an update hook or just push a new temporary
branch name and then use git-update-ref or git-branch directly on
the remote repository.

-- 
Shawn.