| 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 |
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
Status:
WontFix
Oct 6, 2011
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
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
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
What is a status of this issue ? Like Phil wrote it is also a bug to me.
Mar 12, 2013
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
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
Accepted as a bug in 2011, still not fixed in 2014. Any news on this?
Mar 27, 2014
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
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
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
Thanks bklarson. Directly using git push worked.
Jan 28, 2015
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
Do we have to give up with feature branches when using Gerrit (2.11.3 currently)?
Sep 24, 2015
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
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 |