How to ignore changes on remote

My remote branch has changes that are not fast forward (I forgot to merge). I have now made incompatible changes on my local branch. I simply want to use the local version and push it to the remote. I don't care about the remote version. I don't want to merge as there'll be loads of conflicts and the answer will always be 'use the local one'. Is there an easy way to do this? I can't think of anything.

Cheers!

On Tue, 2010-03-23 at 13:54 +0000, Howard Miller wrote:

git push origin +local_branch:remote_branch

Thanks!

Tell me more about that '+'. I've never heard of it before. Can't see anything in the docs (although I'm probably not looking in the right place)

Hello!

HM> Tell me more about that '+'. I've never heard of it before. Can't see HM> anything in the docs (although I'm probably not looking in the right HM> place)

  git help push

<refspec>…
  The format of a <refspec> parameter is an optional plus +, followed
  by the source ref <src>, followed by a colon :, followed by the
  destination ref <dst>. It is used to specify with what <src> object
  the <dst> ref in the remote repository is to be updated.

  ...

  By having the optional leading +, you can tell git to update the
  <dst> ref even when the update is not a fast forward. This does not
  attempt to merge <src> into <dst>. See EXAMPLES below for details.

---=====---
 Alexander

On Tue, Mar 23, 2010 at 3:13 PM, Howard Miller <howardsmiller@googlemail.com> wrote:

man git-push and search for '+', there is even an example like the command above.

HTH, Santi

Not on my docs (1.5.4) but it works anyway. Thanks!

On Tue, 2010-03-23 at 14:13 +0000, Howard Miller wrote:

http://kernel.org/pub/software/scm/git/docs/git-push.html

the '+' means that you want to bypass the security which does not allow non fast-forward pushes.

Note that you shouldn't do non fast-forward pushes to a repository which can be cloned by other people than you. Once published (accessible to anybody) you should do a merge and then push to origin even if you only take your local history in the merge to avoid user pulling from origin conflicts due to the non fast forward history.

Regards.

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?

Also, Howard, what do you mean by "I forgot to merge"? Do other people have push access to this branch? You can't just tell people "use the local version" after you force a push. If anyone has based work off of that point, you're going to get into way more trouble forcing a non-ff push than if you just did a merge and then resolved all the conflicts as --ours.

Scott

On Tue, Mar 23, 2010 at 7:25 AM, Sylvain Rabot <sylvain@abstraction.fr> wrote:

On 23 March 2010 16:05, Scott Chacon <schacon@gmail.com> wrote:

I'm not really fussed. I hope not to make a habit of this. I'll probably forget and ask again next time :)

It's not a repo that particularly matters - just a convenience thing for some test scripts. If it had been on a proper production repo then I would just have dealt with the conflicts.

Am 3/23/2010 17:05, schrieb Scott Chacon:

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

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.

-- Hannes

On Tuesday 23 March 2010, Johannes Sixt wrote:

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.

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 wrote:

Why not have administrator use

         git config --system push.default tracking

once (and/or setup skeleton for /etc/gitconfig)?

On Tuesday 23 March 2010, Jakub Narebski wrote:

Because developers administer their own machines.

...Johan

Scott Chacon <schacon@gmail.com> writes:

I think "-f" would be simpler and easier for people who use only one branch, as there is no "I want to disable only for this branch but still want other branches checked" problem in such a case.

Once they graduate from that and start using more than one branches, "-f" is too broad a brush that disables the check for everything you push out, and you would want to teach "+" as a way to narrow the possible damage.

"git push -f origin this_branch_only" can be used to limit the risk, but if they start from a short-and-lazy "git push -f" without arguments, their finger would have harder time to learn it. There is no such learning curve issue for "+", as you cannot use it without saying for which branch to disable the check.