Pushing to Gerrit fails unexpectedly with 'no new changes'
Edwin Kempin
we came across a use-case in which the push to Gerrit is unexpectedly
failing with 'no new changes':
1. A user does a commit and pushes this commit to the branch 'test'
2. The user notices that it was a mistake to push to the branch
'test', but actually he wanted to push to the 'master' branch.
3. The user goes to Gerrit and abandons the pending change for the 'test' branch
4. The user tries to push the same commit once more but this time to
the 'master' branch. This second push now fails with
$ git push ssh://user@host:29418/my/project HEAD:refs/for/master
Total 0 (delta 0), reused 0 (delta 0)
To ssh://user@host:29418/my/project
! [remote rejected] HEAD -> refs/for/master (no new changes)
error: failed to push some refs to 'ssh://user@host:29418/my/project'
Since this commit actually would mean a change for the 'master' branch
I'm surprised about this error. Is this a bug or is this intended to
fail?
Thanks and best regards,
Edwin
Matthias Sohn
Matthias
Edwin Kempin
succeeds.
If to push the old commit to another branch I would of course expect a new
change-id. Since the commit message does not contain a change-id Gerrit
could simply create a new change-id, doesn't it?
2010/10/5 Matthias Sohn <matthi...@googlemail.com>:
Shawn Pearce
> Yes, if a commit with --amend is done we get a new commit id and the push
> succeeds.
>
> If to push the old commit to another branch I would of course expect a new
> change-id. Since the commit message does not contain a change-id Gerrit
> could simply create a new change-id, doesn't it?
No. Because Gerrit is looking only for commits it has never seen
before. The commit was already seen and assigned to a change on a
different branch, so Gerrit won't create a new change for it. Also,
it would still have the same change-id as the other change because
when there is no change-id in the commit message, the change-id is
just the commit SHA-1 with an "I" thrown in front of it. Since the
commit hasn't changed, its change-id won't be different.
This behavior is probably wrong now. In the earlier days it sounded
correct. But I think everyone is getting more comfortable with using
branches, and this logic just doesn't make sense anymore with the way
people use Gerrit.
Dmitry Fink
create
a different SHA-1 and so Change-Id will also be different.
Anyway, I think there was a different thread about that already and it
was suggested
to use branch/Change-Id pair to uniquely identify a commit and to
allow having different changes
with same Change-Id on different branches, cherry-picking same change
between
different production branches is a common practice and asking people
to amend the commit
message every time is too much :)
Shawn, you mentioned then it shouldn't be too difficult to fix, if you
want I can
give it a try, is there a bug or a feature request to track that?
On Oct 5, 12:02 pm, Shawn Pearce <s...@google.com> wrote:
Bruce Zu
On Saturday, April 6, 2013 11:33:10 PM UTC+8, re...@el-tramo.be wrote:
Hi,Bringing up an old thread now.
On Tuesday, October 5, 2010 9:02:48 PM UTC+2, Shawn Pearce wrote:This behavior is probably wrong now. In the earlier days it sounded
correct. But I think everyone is getting more comfortable with using
branches, and this logic just doesn't make sense anymore with the way
people use Gerrit.
Has this been fixed in the meantime? I'm still seeing this I think, and it means we can't work on changes in a sandbox branch for a while, and then push when we're ready (since the change has already been seen by then, and refs/for/master rejects it).thanks!Remko
Deniz Türkoglu
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.