'No new changes' error too restrictive?
Reported by jer...@davies.name, Nov 22 2011
Affected Version: 2.2.1 What steps will reproduce the problem? 1. Push a commit to a personal/sandbox branch not seen by Gerrit's review mechanisms (i.e. not under refs/heads, nor refs/for, but instead under something like refs/personal/<user>). 2. Now push that same commit to refs/for/blah What is the expected output? What do you see instead? Gerrit rejects the push with a 'no new changes' error, because it has already seen commit. But it has only seen this commit on a sandbox branch, not on any review/integration related branch. Please provide any additional information below. If, in addition to its primary purpose as a review system, I use Gerrit as a convenient way to backup and share personal branches, I may wish to push for review a commit that I have previously pushed to a personal branch. Currently Gerrit forces me to artificially create a new commit for this. A minor annoyance.
Feb 24 2012,
I think this is same issue with topic 'Must Change-Ids be unique across branches?' in Repo and Gerrit Discussion.
Nov 26 2012,
This problem occurs because Gerrit receives only the Sha-1's that have changed, but none of these have changed. Consider this sequence: ## Checkout master git checkout origin/master ## Create a commit echo foo >> flags && git add flags && git commit -m"Change-2" ## Push it to my "backup branch" git push origin HEAD:refs/heads/foo ## Make another commit echo foo >> flags && git add flags && git commit -m"Change-2" ... remote: Processing changes: new: 1, refs: 1, done remote: remote: New Changes: remote: https://somewhere.com/gerrit/3208 remote: To gerrit:testing.git * [new branch] HEAD -> refs/for/master Notice it did not create TWO new commits because it already had one of those changes locally. That change ("Change-1") is not even in the queue for 'master', but Gerrit assumes that it is and that the new commits are the ones the matter. In some cases, this might make sense -- such as on a project which uses "Cherry-pick" for all submitted changes. But on others it may not. But how is Gerrit to decide what to do? In the OP's case, this problem is reduced to just a single commit. But consider the case where I accidentally pushed to the wrong "refs/for/*" branch. Suppose my 'foo' branch has 100 commits which I am not ready to push for review. In this case, Gerrit will ignore 100 commits on my foo branch instead of just 1. To me, this is a good thing. It prevents me from making this mistake: ## Make a change on foo, but accidentally push to refs/for/master git checkout origin/foo echo foo >> flags && git add flags && git commit -m"One foo change" git push origin HEAD:refs/for/master If Gerrit picks this up and creates 100 new review commits in "refs/for/master", I will have a real mess on my hands. Workaround: Use 'git rebase --no-ff' to rewrite all of your commits with new SHA-1's so they are new to Gerrit. ## Make a change on foo, but accidentally push to refs/for/master git checkout origin/foo echo foo >> flags && git add flags && git commit -m"One foo change" git rebase --no-ff origin/master git push origin HEAD:refs/for/master ## Woohoo! 100 new review commits!
Sep 9 2014,
Sep 11 2014,
Sign in to add a comment