How to ignore changes on remote

How to ignore changes on remote

[Howard Miller]

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!

Re: How to ignore changes on remote

[Sylvain Rabot]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Tue, 2010-03-23 at 13:54 +0000, Howard Miller wrote:
> 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!

git push origin +local_branch:remote_branch

-- 
Sylvain Rabot <sylvain@abstraction.fr>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: How to ignore changes on remote

[Howard Miller]

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

Re: How to ignore changes on remote

[Alexander Iljin]

Hello!

>>
>> git push origin +local_branch:remote_branch
>>

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

Re: How to ignore changes on remote

[Santi Béjar]

On Tue, Mar 23, 2010 at 3:13 PM, Howard Miller
<howardsmiller@googlemail.com> 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)

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

HTH,
Santi

Re: How to ignore changes on remote

[Howard Miller]

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

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

Re: How to ignore changes on remote

[Sylvain Rabot]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Tue, 2010-03-23 at 14:13 +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)

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.

-- 
Sylvain Rabot <sylvain@abstraction.fr>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: How to ignore changes on remote

[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?

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 Tue, 2010-03-23 at 14:13 +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)
>
> 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.
>
> --
> Sylvain Rabot <sylvain@abstraction.fr>
>

Re: How to ignore changes on remote

[Howard Miller]

On 23 March 2010 16:05, Scott Chacon <schacon@gmail.com> wrote:
> 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.

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.

Re: How to ignore changes on remote

[Johannes Sixt]

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.

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

Re: How to ignore changes on remote

[Junio C Hamano]

Scott Chacon <schacon@gmail.com> writes:

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

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.

Re: How to ignore changes on remote

[Johan Herland]

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

Re: How to ignore changes on remote

[Jakub Narebski]

Johan Herland wrote:

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

Why not have administrator use

         git config --system push.default tracking

once (and/or setup skeleton for /etc/gitconfig)?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: How to ignore changes on remote

[Johan Herland]

On Tuesday 23 March 2010, Jakub Narebski wrote:
> Johan Herland wrote:
> > 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.
>
> Why not have administrator use
>
>          git config --system push.default tracking
>
> once (and/or setup skeleton for /etc/gitconfig)?

Because developers administer their own machines.


...Johan

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