Ludovic Rousseau wrote: > Gerrit has more than 200 patches still waiting the the backlog. > Many of them can't be merge since they do not 'fast-forward' and must > be rebased by hand. > > Since the git commits were created without a Change-Id: we have 3 > options (I think): > 1. edit each commit message to add the missing Change-Id: > and resubmit a rebased patch > 2. reject all the patches > rebase all the patches > resubmit them as new gerrit entries > 3. reject all the patches > ask for new submission > > I did option 1 for some patches. It is very borring and time consuming. > > Without help (man power) I do plan for option 3.
There's also an option 4, to decide that we want to change the configuration of gerrit to not require fast-forward, and work as if that change has already been done. This means reviewing existing changes and pushing new changes. When review is done and the change is good it gets +2 and may or may not be marked for submit. Once gerrit config has been changed all +2 changes would be applied in order, and a script could pick all up which haven't been explicitly submitted. The problem with this is of course that verification by jenkins will no longer be done for exactly the code that would end up in the repository. jenkins would run with $change added on top of current staging, but the actual inclusion of the change into staging may happen much later. Even if there is no conflict the code could still have changed in a way that jenkins does not catch. Requiring fast-forward completely avoids this problem. I think it might be a sane compromise to temporarily change the configuration, in order to more easily clear the backlog. But if we are to do so I think that there must under no circumstances be any new changes added (into staging) during that time. They can of course still be pushed to gerrit like always. > I do not know if a creating a french OpenSC association to deal with > the project governance will help here. Obviously not. > But people with some free time can surely help move OpenSC. Yes, working on code is always the best way to help a project. > The process is simple. Select a patch and go to its "oldest" unmerged > ancestor. Then do: > > # a. create a merge branch > git branch merge > > # b. go inside local merge branch > git checkout merge Suggest combine the above a. and b. into: git checkout -b change123 staging Where change123 is the name for the new branch that will be created. > # c. get cherry-pick a patch from gerrit > git fetch ... > > # d. add Change-Id: > git rebase -i HEAD~1 The above can be simplified to: git fetch ... && git cherry-pick -e FETCH_HEAD ..which allows editing the commit message directly before doing the cherry-pick. If the message needs to be edited again, run: git commit --amend > The command is "git fetch > https://www.opensc-project.org/codereview/p/OpenSC > refs/changes/45/45/1 && git cherry-pick FETCH_HEAD" Instead of the URL it's also fine to put the name of the remote, in your example that's gerrit. > # e. push > git push gerrit HEAD:refs/for/staging > > # f. go inside staging > git checkout staging Note that for the pull below to have any effect, it's important to submit the updated change in gerrit first. This means waiting for the verification, and then giving review +2 and finally submitting. > In step d. the missing Change-Id: line must be added in the commit > message. In the "git rebase" in interactive mode replace "pick" by > "reword" > Then add the Change-Id: given by gerrit. In this case "Change-Id: > Ifc3b467d8a299897bb7417c8dfd09873f24e46f6" as the last line of the > commit message. Yes, very important. Thanks for the guide! //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
