New issue
Advanced search Search tips

Issue 9024 link

Starred by 4 users

Issue metadata

Status: Released
Owner: ----
Closed: Dec 21
Components:



Sign in to add a comment

WIP/private status not shown in console output when pushing new version

Project Member Reported by david.pu...@gmail.com, May 16 2018

Issue description

*****************************************************************
*****                                                       *****
***** !!!! THIS BUG TRACKER IS FOR GERRIT CODE REVIEW !!!!  *****
*****                                                       *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, CYANOGENMOD,  *****
***** INTERNAL ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.*****
*****                                                       *****
*****   THOSE ISSUES BELONG IN DIFFERENT ISSUE TRACKERS     *****
*****                                                       *****
*****************************************************************

Affected Version: master

What steps will reproduce the problem?
1. Push some changes for review
2. Push another one on top as WIP/private
3. Amend one of the earlier ones in interactive rebase and push new patch sets of the whole series

What is the expected output?

At step 2 the change output is shown with WIP and PRIVATE suffixes
At step 3 the change is still private and WIP, so should have the WIP and PRIVATE suffixes

What do you see instead?

At step 3 the WIP and PRIVATE suffixes are not shown, causing me to think that the WIP and PRIVATE flags had been removed.  In fact the change is still WIP/PRIVATE, it was only missing from the output

Please provide any additional information below.

Initial push of the change as WIP/PRIVATE and has the suffixes:

hooks $ git push origin HEAD:refs/for/stable-2.14%private,wip
Counting objects: 25, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (25/25), 3.84 KiB | 1.28 MiB/s, done.
Total 25 (delta 8), reused 0 (delta 0)
remote: Resolving deltas: 100% (8/8)
remote: Processing changes: new: 1, done
remote:
remote: New Changes:
remote:   https://gerrit-review.googlesource.com/#/c/plugins/hooks/+/178770 Add submit hook [PRIVATE] [WIP]
remote:
To https://gerrit-review.googlesource.com/plugins/hooks
 * [new branch]      HEAD -> refs/for/stable-2.14%private,wip


Subsequent push does not have the suffixes:


hooks $ git push origin HEAD:refs/for/stable-2.14
Counting objects: 25, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (25/25), 3.85 KiB | 1.28 MiB/s, done.
Total 25 (delta 8), reused 0 (delta 0)
remote: Resolving deltas: 100% (8/8)
remote: Processing changes: updated: 3, done
remote: (I) 64e8445: no files changed, message updated
remote: (I) a44e590: no files changed, was rebased
remote: (I) d2c658d: no files changed, was rebased
remote:
remote: Updated Changes:
remote:   https://gerrit-review.googlesource.com/#/c/plugins/hooks/+/178750 Improve hooks documentation structure
remote:   https://gerrit-review.googlesource.com/#/c/plugins/hooks/+/178751 Reword documentation of ref-update and commit-received hooks
remote:   https://gerrit-review.googlesource.com/#/c/plugins/hooks/+/178770 Add submit hook
remote:
To https://gerrit-review.googlesource.com/plugins/hooks
 * [new branch]      HEAD -> refs/for/stable-2.14
 
I have encountered another case where the WIP/private status in the console output is wrong, although in a different way. This is in Gerrit 2.16.

Here's the output from the push:
$ git push
Enumerating objects: 92, done.
Counting objects: 100% (92/92), done.
Delta compression using up to 20 threads
Compressing objects: 100% (58/58), done.
Writing objects: 100% (60/60), 13.53 KiB | 4.51 MiB/s, done.
Total 60 (delta 44), reused 2 (delta 0)
remote: Resolving deltas: 100% (44/44)
-it co remote: Processing changes: new: 1, updated: 5 (-)
remote: Processing changes: refs: 1, new: 1, updated: 5, done   
remote:
remote: SUCCESS
remote:
remote: New Changes:
remote:   https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/17855 MXGDA-3119 Use master filename when recording Eiger data collection in ISPyB
remote:
remote: Updated Changes:
remote:   https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/17629 [DO NOT PUSH] I03/I04: switch to Eiger [PRIVATE]
remote:   https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/17729 MXGDA-3212 Make I03/I04 beamLineSpecificEnergy Pilatus-independent [PRIVATE]
remote:   https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/17730 DummyAreaDetectorPilatus: don't disable auto gain when setting initial gain [PRIVATE]
remote:   https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/17741 MXGDA-3119 EigerDetectorWrapper: tweak set_threshold & implement create_set_t... [PRIVATE]
remote:   https://gerrit.diamond.ac.uk/c/gda/gda-mx/+/17742 MXGDA-3224 Work around lack of Eiger delay time parameter [PRIVATE]
remote:
To ssh://gerrit.diamond.ac.uk:29418/gda/gda-mx.git
 * [new branch]          HEAD -> refs/for/gda-9.10

The problem here is that only the first of the "Updated Changes", 17629, is actually private, but all the other changes in the list say "[PRIVATE]" as well, even though they are not. This is the reverse to the first problem report, but likely has the same underlying cause.

I also note that the order of entries in the list of "Updated Changes" appears to be increasing old-style change number (i.e. oldest to newest by time of first upload). Reporting in the order of the relation chain (I think that's possible; not sure) would be more useful.

> I also note that the order of entries in the list of "Updated Changes" appears to be increasing old-style change number

That's a separate issue.  There's a change in progress to make it show the changes in relation order:

https://gerrit-review.googlesource.com/c/gerrit/+/204492
Status: Started (was: New)
This is still reproducible on the head of stable-2.15.
Status: ChangeUnderReview (was: Started)
https://gerrit-review.googlesource.com/c/gerrit/+/207310
Project Member

Comment 5 by luca.mil...@gmail.com, Dec 21

Labels: FixedIn-2.16.2
Status: Released (was: ChangeUnderReview)

Sign in to add a comment