Improve error output when pushing a fast-forward branch

[GoogleCodeExporter]

Affected Version: 2.2.1

What steps will reproduce the problem?

Start with a topic branch "foo". It is behind the master branch by a few 
commits. I want to merge master into foo. 
1. Check out branch "foo".
2. Do the merge: "git merge origin/master". This command succeeds and says that 
it was a fast-forward.
3. Attempt to push these new commits to the topic branch "foo" by running "git 
push origin HEAD:refs/for/foo". This command fails with the message "remote 
rejected [...] no new changes".

Here's the command line session:

$ git reset --hard origin/foo
HEAD is now at f0352e4 Merge "Refactor: remove unused entity_url variable" into 
foo
$ git merge origin/master
Updating f0352e4..fd7dfaf
Fast-forward
 app/controllers/application_controller.rb    |   17 +++-
 ...
$ git push origin HEAD:refs/for/foo
Total 0 (delta 0), reused 0 (delta 0)
To ssh://pawlowski@gerrit:29418/repo
 ! [remote rejected] HEAD -> refs/for/foo (no new changes)
error: failed to push some refs to 'ssh://pawlowski@gerrit:29418/repo'

What is the expected output? What do you see instead?
Since there's no merge commit, I guess I didn't really expect this to work. But 
now I'm stumped: how can I push these commits up to my topic branch without 
making another bogus commit to change the git hash?

Original issue reported on code.google.com by pet...@gmail.com on 6 Oct 2011 at 2:20

[GoogleCodeExporter]

To the best of my knowledge, you have 2 options currently -

1. Force push to refs/heads.  It is just a fast-forward, so in theory 
everything has already been reviewed and verified.  There is no point in doing 
so again, so just skip that process and push to refs/heads rather than refs/for.

2. Go ahead and create a merge commit.  Use 'git merge --no-ff' - this will 
create a merge commit even though it isn't necessary in your fast-forward 
situation.  Then the merge commit can be uploaded, reviewed, verified, and 
merged like normal.

My company tends to go with option 2.  I'll close this as wontfix, but if you 
have any suggestions on how to do this better please let us know.

Original comment by bklarson@gmail.com on 6 Oct 2011 at 8:42

• Changed state: WontFix

[GoogleCodeExporter]

Thanks for your help! Option #2 definitely seems like the way to go... I was 
looking for an argument like --no-ff like that but wasn't quite able to find it.

Perhaps the way that Gerrit could help with this situation is to output a 
helpful message, suggesting both of the options that you listed above. If it's 
possible for Gerrit to determine that I am trying to push a fast forward, it 
could say something like "no new changes; to push a fast-forward, force a merge 
commit with '--no-ff' or force it straight to ref/heads".

Original comment by pet...@gmail.com on 6 Oct 2011 at 8:55

[GoogleCodeExporter]

That seems like a good suggestion.  I think we could detect that you are 
pushing already accepted commits to a branch which doesn't yet have those 
commits.

Original comment by bklarson@gmail.com on 6 Oct 2011 at 8:58

• Changed title: Improve error output when pushing a fast-forward branch
• Changed state: Accepted
• Added labels: Priority-Trivial
• Removed labels: Priority-Minor

[GoogleCodeExporter]

To me, this is a bug.

I have branches A and B with common ancestry.
Developers push changes to A where they get cursory reviews for inclusion.
A manager wants to review changes before they go into B.  We have two paths:

  git push origin A:refs/for/B
The manager wants to put the changes through the review cycles for B now (where 
they have never been before).  But this fails (no new changes) as complained 
about in this issue.

  git push origin A:refs/heads/B
The manager wants to just put all the changes through to branch B without 
review, but he can't because, again, "no new changes".  Do I really need to 
give him "force push" permission to do this?

Original comment by phil.hord on 14 Nov 2011 at 11:46

[GoogleCodeExporter]

What is a status of this issue ? Like Phil wrote it is also a bug to me.

Original comment by Iso.poc...@gmail.com on 27 Nov 2012 at 8:52

[GoogleCodeExporter]

Any update on it? It is also bug to me.

Suggestion 2 doesn't seems to be good to me. It creates meaningless merge 
commit.

Original comment by nereu...@gmail.com on 13 Mar 2013 at 12:58

[GoogleCodeExporter]

I have the same kind of situation. With either manual push command (git push 
origin A:refs/heads/B) or with git merge --no-ff option i was able to send it 
for review. But the files showing in git review web page does not contains all 
of my actual file differences between those two branches. It only showing 16 
files diff out of 235 actual file changes.

Original comment by samba...@gmail.com on 22 May 2013 at 5:38

[GoogleCodeExporter]

Accepted as a bug in 2011, still not fixed in 2014. Any news on this?

Original comment by m...@ldiamond.net on 13 Feb 2014 at 8:23

[GoogleCodeExporter]

We had a crash in our Gerrit DB and re-installed it. As the meta-data was lost, 
we simply want to re-push all changes again based on previously pushed commits 
found in refs/changes/* to make Gerrit re-create the change meta-data (as 
suggested by Shawn Pearce at [1]. But when doing this using "git push origin 
<commitid>:refs/for/master" we also get the same error:

me [~/dev/git/products]> git push origin 
80ebc7c6c45d03521104cfc424bc16341feac797:refs/for/master
Counting objects: 43, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 727 bytes | 0 bytes/s, done.
Total 7 (delta 4), reused 3 (delta 0)
remote: Resolving deltas: 100% (4/4)
remote: Processing changes: refs: 1, done    
To ssh://me@gerrit:29418/products
 ! [remote rejected] 80ebc7c6c45d03521104cfc424bc16341feac797 -> refs/for/master (no new changes)
error: failed to push some refs to 'ssh://me@gerrit:29418/products'

Is there any workaround WITHOUT changing the commits? Again, all we want is to 
push the commits again for Gerrit tore-create the change meta-data.

[1] https://groups.google.com/d/msg/repo-discuss/5Gboxg-nM34/2TMVCgCZHTwJ

Original comment by wolfgang...@fluidops.com on 27 Mar 2014 at 8:13

[GoogleCodeExporter]

I tried the --no-ff solution outlined above. When I try to push my merge commit 
I get an error during the rebase:

$ git review  master
Errors running git rebase -i remotes/gerrit/master
error: could not apply 57183e5... Blah Blah Blah

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
Could not apply 57183e5... Blah Blah Blah

Original comment by hmtava...@gmail.com on 31 Mar 2014 at 3:43

[GoogleCodeExporter]

I don't use git review, but yeah it shouldn't be trying to rebase a merge 
commit.  That will cause issues.  Just use git push to upload your change for 
review.  This is discussed in the documentation[1].

[1] https://gerrit-review.googlesource.com/Documentation/user-upload.html

Original comment by bklarson@gmail.com on 31 Mar 2014 at 4:04

[GoogleCodeExporter]

Thanks bklarson. Directly using git push worked.

Original comment by hmtava...@gmail.com on 31 Mar 2014 at 9:08

[GoogleCodeExporter]

Still a problem here. git push is very dangerous and only the project owner has 
that permission (on a separate account to avoid accidents).

Original comment by kresimir...@cloudsensesolutions.com on 28 Jan 2015 at 4:36