Re: How to ignore changes on remote

[Johan Herland <johan@herland.net>]

On Tuesday 23 March 2010, Johannes Sixt wrote:
> 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