Merge after importing a project to gerrit fails because of missing Change-Ids in old commits

[euphxenos]

We have a project that just moved from an Atlassian Stash server to our Gerrit server.  After this migration, a user tried to merge recent changes from master into some other branch he's working on.  Some of the changes he needs to merge were from before the migration, and some were from after.  After his merge, he was unable to push to the Gerrit server because some of the commits he just merged are missing Change-Ids.  This isn't surprising, because those commits were committed into the repository while it was still hosted on something other than a Gerrit server (still git, but it didn't use Change-Ids).  The project is configured to require Change-Ids in commit messages.  It's well understood why this is happening, but I'm uncertain what we should do about it.  So far the best idea I've got is to temporarily change the config on this project to not require a Change-Id in commit message when one of these merges fails, then turn that config setting back on after it gets pushed.  Is there a better approach that I'm missing?

thanks,

--Andrew

[Saša Živkov]

On Tue, Jan 24, 2017 at 2:13 AM, euphxenos <euph...@gmail.com> wrote:

We have a project that just moved from an Atlassian Stash server to our Gerrit server.  After this migration, a user tried to merge recent changes from master into some other branch he's working on.  Some of the changes he needs to merge were from before the migration, and some were from after.  After his merge, he was unable to push to the Gerrit server because some of the commits he just merged are missing Change-Ids.

Commits which are already merged into a branch (in Gerrit) will not cause creation of a new change... unless you enabled

the "Create a new change for every commit not in the target branch" for that project.

 

This isn't surprising, because those commits were committed into the repository while it was still hosted on something other than a Gerrit server (still git, but it didn't use Change-Ids).

 

The project is configured to require Change-Ids in commit messages.  It's well understood why this is happening, but I'm uncertain what we should do about it.  So far the best idea I've got is to temporarily change the config on this project to not require a Change-Id in commit message when one of these merges fails, then turn that config setting back on after it gets pushed.  Is there a better approach that I'm missing?

I guess that all existing commits should be just imported into Gerrit without pushing them for code-review?

Are you trying to import by pushing everything to refs/for/master? Why?

 

thanks,

--Andrew

--
--
To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[euphxenos]

On Wednesday, January 25, 2017 at 5:36:03 AM UTC-8, zivkov wrote:

On Tue, Jan 24, 2017 at 2:13 AM, euphxenos <euph...@gmail.com> wrote:

We have a project that just moved from an Atlassian Stash server to our Gerrit server.  After this migration, a user tried to merge recent changes from master into some other branch he's working on.  Some of the changes he needs to merge were from before the migration, and some were from after.  After his merge, he was unable to push to the Gerrit server because some of the commits he just merged are missing Change-Ids.

Commits which are already merged into a branch (in Gerrit) will not cause creation of a new change... unless you enabled

the "Create a new change for every commit not in the target branch" for that project.

 

This isn't surprising, because those commits were committed into the repository while it was still hosted on something other than a Gerrit server (still git, but it didn't use Change-Ids).

 

The project is configured to require Change-Ids in commit messages.  It's well understood why this is happening, but I'm uncertain what we should do about it.  So far the best idea I've got is to temporarily change the config on this project to not require a Change-Id in commit message when one of these merges fails, then turn that config setting back on after it gets pushed.  Is there a better approach that I'm missing?

I guess that all existing commits should be just imported into Gerrit without pushing them for code-review?

Are you trying to import by pushing everything to refs/for/master? Why?

No we're not trying to import by pushing everything to refs/for/master, we've already got the entire repository imported.  We did a git clone --mirror from the old Stash server, then pushed that into the new Gerrit server.  After that was done and the repo was on our Gerrit server, we set up the permissions, and a user is now trying to do a git merge from master into another branch and push the results of that merge back to the Gerrit server.  Changes to his target branch are supposed to go through code review.  Since his merge straddles changes from either side of the migration, some of them have Change-Ids and some don't.  Going forward, new changes will have Change-Ids, which is why I really don't want to turn off requiring them in the config for that repo.

This seems like it would be a pretty common issue for a projecting migrating into Gerrit.  How have others handled it?

thanks,

--Andrew

[Saša Živkov]

On Wed, Jan 25, 2017 at 7:15 PM, euphxenos <euph...@gmail.com> wrote:

On Wednesday, January 25, 2017 at 5:36:03 AM UTC-8, zivkov wrote:

On Tue, Jan 24, 2017 at 2:13 AM, euphxenos <euph...@gmail.com> wrote:

We have a project that just moved from an Atlassian Stash server to our Gerrit server.  After this migration, a user tried to merge recent changes from master into some other branch he's working on.  Some of the changes he needs to merge were from before the migration, and some were from after.  After his merge, he was unable to push to the Gerrit server because some of the commits he just merged are missing Change-Ids.

Commits which are already merged into a branch (in Gerrit) will not cause creation of a new change... unless you enabled

the "Create a new change for every commit not in the target branch" for that project.

 

This isn't surprising, because those commits were committed into the repository while it was still hosted on something other than a Gerrit server (still git, but it didn't use Change-Ids).

 

The project is configured to require Change-Ids in commit messages.  It's well understood why this is happening, but I'm uncertain what we should do about it.  So far the best idea I've got is to temporarily change the config on this project to not require a Change-Id in commit message when one of these merges fails, then turn that config setting back on after it gets pushed.  Is there a better approach that I'm missing?

I guess that all existing commits should be just imported into Gerrit without pushing them for code-review?

Are you trying to import by pushing everything to refs/for/master? Why?

No we're not trying to import by pushing everything to refs/for/master, we've already got the entire repository imported.

If you imported everything then only newly created commits will be pushed, and all newly created commits

will have a Change-Id in their commit message. If this is not the case then I still don't understand something about

your migration.

We did a git clone --mirror from the old Stash server, then pushed that into the new Gerrit server.  After that was done and the repo was on our Gerrit server, we set up the permissions, and a user is now trying to do a git merge from master into another branch and push the results of that merge back to the Gerrit server.

In this case I expect that exactly one commit will be pushed, the merge commit.

If this push tries to create more than one change then either I don't understand your migration,

or the user doing merge is doing something wrong.

My understanding is that both commits which were merged by the user are already present in Gerrit and merged in some branch(es).

 

Changes to his target branch are supposed to go through code review.  Since his merge straddles changes from either side of the migration,

Ah, so after the initial import you want to continue the process by fetching from Stash, merging into master and pushing for review?

IMHO, the commits fetched from Stash shouldn't be pushed for review as they are already accepted in Stash.

 

some of them have Change-Ids and some don't.  Going forward, new changes will have Change-Ids, which is why I really don't want to turn off requiring them in the config for that repo.

This seems like it would be a pretty common issue for a projecting migrating into Gerrit.  How have others handled it?

It looks to me that after your initial migration you still allow new commits in Stash?

Why would you do that? Why not continue in Gerrit only?