New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 26 users

Issue metadata

Status: Submitted
Owner:
User never visited
Closed: Sep 2014



Sign in to add a comment

'No new changes' error too restrictive?

Reported by jer...@davies.name, Nov 22 2011

Issue description

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.

 
 I think this is same issue with topic 'Must Change-Ids be unique across branches?' in Repo and Gerrit Discussion.

Comment 2 by phil.h...@gmail.com, 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!


Owner: de...@spotify.com
Status: ChangeUnderReview
https://gerrit-review.googlesource.com/#/c/59909/
Project Member

Comment 4 by de...@spotify.com, Sep 11 2014

Status: Submitted

Sign in to add a comment