Re: How to ignore changes on remote

From: Johan Herland <johan@herland.net>
Date: Mar 23, 2010, 17:20 UTC
Message-ID: <201003231820.51618.johan@herland.net>
In-Reply-To: <4BA8EA6A.4030607@viscovery.net>

On Tuesday 23 March 2010, Johannes Sixt wrote:

Show 13 quoted lines

> Am 3/23/2010 17:05, schrieb Scott Chacon:
> > Why would we teach someone to do that instead of just recommending
> > the far less obscure 'git push -f'?  A leading '+' on the refspec
> > is ridiculously confusing compared to "just tell it to force the
> > push with -f".  Am I forgetting something?
>
> -f is dangerous. I was once bitten badly by a hastily typed
>
>    git push -f repo
>
> that pushed two branches instead of only one: One needed an urgent
> update (that was the good one), but it also pushed the other one,
> which was not yet prepared for publication.

IMHO the main problem in this case is NOT with the -f option, but rather that 'git push' defaults to pushing all "matching" branches. I'd much rather have push.default default to the much safer "tracking", which pushes at most one branch. But changing default behaviour is hard to do without annoying old-timers.

I'm rolling out Git at my $DAYJOB to a few hundred developers, and I instruct them to

	git config --global push.default tracking

immediately after installing Git. Which sucks, but is the only sane thing I can do to prevent this problem from haunting us.

> By teaching the +refspec form, you force the user to be careful which
> branch is rewound. Yes, you can still say +refs/heads/*, but if you
> do that, you are much more explicit than with "push -f repo", where
> the affected branches are hidden in the config file.

IME refspecs are not easily grasped by Git newbies, and the longer they can get by without having to learn them, the happier they'll be with Git. IMHO, refspecs are really cool and powerful, but you shouldn't have to learn them in order to do day-to-day development.

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net