My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 1145: Improve error output when pushing a fast-forward branch
41 people starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----


Sign in to add a comment
 
Reported by pet...@gmail.com, Oct 6, 2011
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?

Oct 6, 2011
Project Member #1 bklarson@gmail.com
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.
Status: WontFix
Oct 6, 2011
#2 pet...@gmail.com
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".
Oct 6, 2011
Project Member #3 bklarson@gmail.com
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.
Summary: Improve error output when pushing a fast-forward branch
Status: Accepted
Labels: -Priority-Minor Priority-Trivial
Nov 14, 2011
#4 phil.hord
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?


Nov 27, 2012
#5 Iso.poc...@gmail.com
What is a status of this issue ? Like Phil wrote it is also a bug to me.
Mar 12, 2013
#6 nereu...@gmail.com
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.
May 21, 2013
#7 samba...@gmail.com
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.
Feb 13, 2014
#8 m...@ldiamond.net
Accepted as a bug in 2011, still not fixed in 2014. Any news on this?
Mar 27, 2014
#9 wolfgang...@fluidops.com
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
Mar 31, 2014
#10 hmtava...@gmail.com
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

Mar 31, 2014
Project Member #11 bklarson@gmail.com
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
Mar 31, 2014
#12 hmtava...@gmail.com
Thanks bklarson. Directly using git push worked.
Jan 28, 2015
#13 kresimir...@cloudsensesolutions.com
Still a problem here. git push is very dangerous and only the project owner has that permission (on a separate account to avoid accidents).
Sep 22, 2015
#14 cezarius...@gmail.com
Do we have to give up with feature branches when using Gerrit (2.11.3 currently)?
Sep 24, 2015
#15 sschuberth
I think the new project configuration option named "Create a new change for every commit not in the target branch" is supposed to tackle this situation. From [1]:

"This option is useful if you want to push a change to your personal branch first and for review to another branch for example. Or in cases where a commit is already merged into a branch and you want to create a new open change for that commit on another branch."

[1] https://gerrit-review.googlesource.com/Documentation/project-configuration.html#_use_target_branch_when_determining_new_changes_to_open
Oct 29, 2015
#16 freeman....@gmail.com
What if a git branch was not managed by Gerrit before and now needs to be merged into a Gerrit managed branch?

If we just directly push the merge commit to refs/heads, will that confuse/mess up Gerrit in the future?

If bklarson's 2nd option, 'git merge --no-ff', works too for this case it will be even better.
Sign in to add a comment

Powered by Google Project Hosting