multiple Change-Id lines in commit message when trying to push gerrit source code into gerrit

566 views
Skip to first unread message

Kris

unread,
May 16, 2011, 12:23:54 PM5/16/11
to Repo and Gerrit Discussion
Hi,

I'm trying to push gerrit source into a gerrit project, doing
following steps:
1) download and extract gerrit source code
2) create gerrit project inside a gerrit + add group permissions
3) push a gerrit source: git push ssh://git-imc:50000/gerrit_source/gerrit_source_test5
HEAD:refs/head/master

This gives me following error:
Counting objects: 32257, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9445/9445), done.
Writing objects: 100% (32257/32257), 8.40 MiB | 10.82 MiB/s, done.
Total 32257 (delta 18023), reused 30270 (delta 16411)
remote: Resolving deltas: 100% (18023/18023)
To ssh://git-imc:50000/gerrit_source/gerrit_source_test5
! [remote rejected] HEAD -> refs/head/master (multiple Change-Id
lines in commit message)
error: failed to push some refs to 'ssh://git-imc:50000/gerrit_source/
gerrit_source_test5'

Could you please advise how to check in gerrit source, preserving the
history of the project.

Thanks,
Kris

Shawn Pearce

unread,
May 16, 2011, 9:57:08 PM5/16/11
to Kris, Repo and Gerrit Discussion

You will have to import the project "behind the scenes". As the server
administrator, just push directly into the server managed repository.
Or cd into it and execute `git fetch URL HEAD:refs/heads/master` to
fetch directly into the repository.

Kris

unread,
May 17, 2011, 4:40:35 AM5/17/11
to Repo and Gerrit Discussion
Direct push into a repository didn't work, but git fetch worked!
Thanks for help.

Kris

On May 17, 3:57 am, Shawn Pearce <s...@google.com> wrote:

Andrew Wheeler

unread,
Aug 30, 2011, 12:27:24 PM8/30/11
to repo-d...@googlegroups.com, Kris
Hey Shawn, 

Long time reader, first time poster.  Thanks for your work on Gerrit.

We're running into this problem since we upgraded from 2.1.6 to 2.1.8. Looks like most of the Change ID validation came in with 2.1.7.  Because we and our partners have been running pre-2.1.7 gerrits for a long time we have many branches with commits that have duplicate/invalid Change IDs.  So SCM folks are having a hard time pushing these branches around.

Is the "behind the scenes push" the only planned solution?  Unfortunately the number of folks that have behind-the-scenes privs is low, so the current model is that we get someone with behind-the-scenes privs to help do the push.  This bottlenecks our branch pushes.  

I submitted a tentative gerrit patch to our gerrit team that bypasses much of the Change-Id validation for pushes to refs/heads/*.  What I'm trying to figure out is why we'd want to validate Change IDs during a push to refs/heads/*, ever, given the number of invalid Change IDs floating around our branches.  Would bypassing the validation and thus pushing invalid/duplicate/missing Change IDs cause any gerrit problems?  Other than a general concern for SCM folks pushing *new* commits with bad Change-IDs, can you think of any other problems with removing this restriction? 

Thanks,

-andrew

Luthander, Fredrik

unread,
Aug 31, 2011, 4:04:29 AM8/31/11
to repo-d...@googlegroups.com, Kris

Hi Andrew,

 

On my $DAYJOB I saw a lot of those problems  as well (when you go to the change webpage you get a big NOT FOUND instead of a change.) when we upgraded from 2.1.6 to 2.1.7/2.1.8.

 

Every time you try to upload a change or patch set, starting with 2.1.7, Gerrit checks all other changes/patch sets in the same git like you describe. The trick is to convince it to stop looking at these broken open changes.

 

What we did was we did a little database-hacking for each of the changes that affects uploads; we had to change them to the abandoned state manually in the database, since the webpage is no longer available.

 

Now, if we look at the database for 2.1.x we find that changes has its own table with the following fields:

 

                                                Table "public.changes"

        Column        |           Type           |                              Modifiers                             

----------------------+--------------------------+---------------------------------------------------------------------

created_on           | timestamp with time zone | not null default '1900-01-01 00:00:00+01'::timestamp with time zone

last_updated_on      | timestamp with time zone | not null default '1900-01-01 00:00:00+01'::timestamp with time zone

sort_key             | character varying(16)    | not null default ''::character varying

owner_account_id     | integer                  | not null default 0

dest_project_name    | character varying(255)   | not null default ''::character varying

dest_branch_name     | character varying(255)   | not null default ''::character varying

open                 | character(1)             | not null default 'N'::bpchar

status               | character(1)             | not null default ' '::bpchar

nbr_patch_sets       | integer                  | not null default 0

current_patch_set_id | integer                  | not null default 0

subject              | character varying(255)   | not null default ''::character varying

row_version          | integer                  | not null default 0

change_id            | integer                  | not null default 0

change_key           | character varying(60)    | not null

topic                | character varying(255)   |

 

Looking at the definition of this table, we see open and status, they're interesting to us.

 

So, what values can they have?

 

reviewdb=> select status from changes group by status;

status

--------

M

n

A

s

(4 rows)

 

reviewdb=> select open from changes group by open;

open

------

Y

N

(2 rows)

 

reviewdb=>

 

Those values in status have meanings which come into play in our problem.

The upper case letters represents states in closed changes, so they'll only exist together with the N-state in open, and vice versa with lower case letters.

 

M = merged

A = abandoned

s = submitted/queued for merge

n = not submitted

So, when querying your own database, you'll find that the changes showing up in the server log as broken will be in state (open=Y, status=n), and to close them we have to change them to (open=N, status=A).

 

In conclusion then, run this SQL line for each of your broken changes:

 

reviewdb=> update changes set (open, status) = ('N', 'A') where change_id = MY_BROKEN_CHANGE_ID_NUMBER;

 

In this example, please check the syntax of the SQL one time extra (instead of trusting me blindly that is), as well as replace the string MY_BROKEN_CHANGE_ID_NUMBER with an actual change_id number. :-)

 

Oh, and there might even be more broken changes surfacing once you've fixed the first ones that's causing trouble. I recommend you take a developer that has problems uploading and ask him to upload repeatedly while fixing the ones that show up to just get through them all quickly.

 

Good luck, and I hope your devs will be able to upload themselves shortly. J

 

--

Best regards,

    Fredrik Luthander

Sony Ericsson Mobile Communications AB

Reply all
Reply to author
Forward
0 new messages