Re: git refusing to merge branches when pulling using a refspec

[Junio C Hamano <gitster@pobox.com>]

Santiago García Pimentel <santiago@garciapimentel.com> writes:

> Hello,
>
> I'm dealing with a small automation (CI) to synchronise some specific branches between two git repositories.
>
> I need to sync a branch with other using a user-given refspec. e.g.
>
> $ git pull origin "refs/heads/branchOrigin:refs/heads/branchDestination”.
>
> (I’ll have a list of refspecs, but so far Im trying to make it work with one)
>
> When the branch can be fast-forwarded there is no problem, but I cannot manage to make it work when it cant.
>
> I just. get the message "[rejected] branchOrigin -> branchDestination (non-fast forward)."
With the "pull" command above, you are doing two logically
independent things.  Do you really need to do both?

 * git pull "<remote>" "<src>:<dst>" first does a "git fetch" to
   locally update <dst> with the commit that is pointed at by <src>
   at the <remote> repository.

 * then, into the currently checked out HEAD, the <src> taken from
   <remote> is merged into.

If you do not need to update <dst> locally, don't give :<dst> part
on the command line.

If you do need to update <dst> locally and safely, then thank that
you got the [rejected] message.  Because the <src> was updated at
the <remote> side that is not based on what you have at <dst>
locally, you may be losint commits from your local <dst> if you let
the first stage of the "git pull" go through, and that is what the
failing command is about.

If you do need to update <dst> locally but you do not have anything
valuable on <dst> locally (in other words, <dst> is used only to
keep track of <src> at <remote>, and if <remote> rewinds the history
of their <src> and loses some commits, you want to lose these commits
the same way from your <dst>), then add "+" before the refspec, i.e.

    git pull "<remote>" "+<src>:<dst>"