How to do a fast-forward merge without a checkout?

Huh?  What does he mean by that?

I have the following in my .git/config file:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = somehost:path/to/repo
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "wpd"]
	remote = origin
	merge = refs/heads/wpd

I have been working on my "wpd" branch on a couple of different machines and have been happily committing, pushing, and pulling from my "origin" host. Recently, however, somebody committed a change on the "master" branch. Now, when I do a "git push", I get the following

$ git push
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 715 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To somehost:path/to/repo
   e1004df..bad8767  wpd -> wpd
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'somehost:path/to/repo'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

The last time I encountered this, I did a "get checkout master; git merge origin/master; git checkout wpd; git push" and that worked. I happen to know that master is a direct descendent of origin/master and that, if I do this again, I will (once again) do a fast-forward merge to bring master up to origin/master.

This may have been fixed in a more recent git (I'm using git 1.7.2.5 on a Debian 6 box and 1.7.4.1 on an RHEL 5 box).

There has got to be an easier way to fix this than checking out the master branch, performing the fast-forward merge, and then switching back to my working branch.

One way would be if there were some way to do a fast-forward merge on a branch without actually checking out that branch. Hence my question.

Another way would be to remove the "master" branch from my config file.

Or perhaps I set up something wrong.

--wpd

Am 7/18/2011 16:18, schrieb Patrick Doyle:

...

[Context: Patrick works on the topic branch, but can't push it anymore because the unrelated branch master was moved forward by someone else.]

After the obligatory 'git fetch', there are at least two ways to do this:

(1) The quick and unsafe way:

    $ git branch -f master origin/master

(2) The safer way:

    $ git push . origin/master:master

The second command is safer because it checks that origin/master is indeed a direct descendent of master.

-- Hannes

On Mon, Jul 18, 2011 at 11:08 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:

I like it! (#2) It's obscure as all get-out, as UNIX commands were intended to be, does the job you need it to do in a manner that is intuitive, provided you understand what it's doing, and if you miss the dot (perhaps, hypothetically speaking of course, because you thought it was a dust spec on your screen when you tried out the command), you get a very obscure error message (errr, hypothetically speaking of course).

Seriously... Thanks for the quick answers. I'll tuck #2 into my bag o' tricks. In the mean time, I need to decide whether I really care about my master branch or not. I do care about origin/master, but I do all my work on wpd and merge in changes from origin/master at random points in time.

Thanks again.

--wpd

On Mon, Jul 18, 2011 at 4:18 PM, Patrick Doyle <wpdster@gmail.com> wrote:

another way to avoid pushing the master branch is to explicitely name the branch to push (wpd):

    $ git push origin wpd

cheers, daniel

On Mon, Jul 18, 2011 at 12:08 PM, knittl <knittl89@googlemail.com> wrote:

Thanks... I thought of that, but being basically lazy and not wanting to have to type all of those extra characters every time I did a "git push", I wanted to figure out a better way.

Seth Milliken posted a great explanation and alternative solution in a
comment to a blog post I found at
http://ken-blog.krugler.org/2010/02/25/git-failed-to-push-some-refs-the-multiple-branch-variant/.
 He suggested doing:

$ git config remote.origin.push HEAD

So that "git push" would default to only pushing the current branch. I like that approach to my underlying problem as well.

But I stand in awe of Hanne's solution (#2) for it's brevity, the fact that it does _exactly_ what I was asking about, and that the capability is already baked into git.

--wpd

On Mon, Jul 18, 2011 at 6:13 PM, Patrick Doyle <wpdster@gmail.com> wrote:

I can understand your laziness ;)

I prefer to use

    $ git config --global push.default current

which tells git to push the current branch to a branch of the same name (for every repository). Another possible (and useful) value is "upstream"/"tracking": push the current branch to it's upstream. Have a look at the git config manpage for more options.

Yup, pushing into the current repository to fast-forward branches without checkout is quite neat indeed :)

Daniel