Re: git pull for update of netdev fails.

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 20, 2006, 17:10 UTC
Message-ID: <20060920171012.GF23260@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0609200942550.4388@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> wrote:

Show 9 quoted lines

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

Show 8 quoted lines

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

Show 7 quoted lines

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