Re: How to update a remote branch (remotes/origin/dev/guile-v2-work)

[David Kastrup]

Thomas Morley <address@hidden> writes:

> (3) updating it
>
> $ git rebase master
> [skipping output, resolving merge-conflicts, applying additional patches]
>
>
> (4) attempt to push in order to make the updates public
>
> $ git push origin HEAD:dev/guile-v2-work
> To ssh://address@hidden/srv/git/lilypond.git
>  ! [rejected]        HEAD -> dev/guile-v2-work (non-fast-forward)
> error: failed to push some refs to
> 'ssh://address@hidden/srv/git/lilypond.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
>
> Obviously I did something wrong.
> What would be the correct method?

Nothing wrong.  Your branch is now rebased on master, meaning that it
consists of commits on top of master.  That also means that it does not
consist of commits on top of the old branch.

Rebasing a branch means that the only sensible way forward afterwards is
to _delete_ the old branch and push a new one (or do a forced update but
Savannah is configured not to allow them).

If you are really sure that your branch's commits are fine, you delete
with

    git push origin :refs/heads/dev/guile-v2-work

and then push your current state with

    git push origin HEAD:refs/heads/dev/guile-v2-work

Note that you can, in theory, delete the old branch just writing

    git push origin :dev/guile-v2-work

and git will find the right reference to delete.  But you cannot push
the replacement in the same manner since once the old reference is gone,
disambiguation between various reference types (branches, tags,
whatever) no longer has anything to go by.  So in order not to make
mistakes, I use the full reference both for deleting and repushing.

So why rebase at all?  Sometimes this repeated work for a long-running
branch is just not done and instead only merge commits with master are
made.  Those are then a descendent of both branch and master (and can
consequently be pushed to either without deletion).  Less work, but also
sometimes hard to see what actually happened.  This makes sense when
several people work continuously on the same branch, like the
translation branches.

-- 
David Kastrup