Gerrit’s brute-force mode, if everything else fails
There’s an convinient and quite easy way to get yourself back to work, once you stucked with something really stupid (most likely — changes’ dependencies, a Gerrit’s Prime Hell) and everything else fails. It is a brute-force mode, that actually don’t mess too much and may help in amy hopeless situations.
Suppose you have some changes (commits) done on your local repository and pushed to Gerrit, but since they’re dependent on something (another change, some patch set or because Gerrit just have a worse day), their waiting with beloved by any Gerrit’s user status “Merge pending”. How to deal with that?
Well… rebasing such change is a first strike method. It goes like this:
- Checkout master and pull the latest repository (
- Checkout that “waiting” change (branch).
- Rebase its contents onto current repository state (
git rebase origin/master).
- Push replacement upload (in most cases use standard
git push) and review the change again in Gerrit UI.
But, to be honest, in really twixed, annoying cases (when Gerrit has really, really bad day), this won’t help.
Now, it is time for our brute-force method:
- Copy entire project’s folder (except
.gitfolder) to some other place. Use system tools, not Git’s one, to copy.
- Abandon all conflicted, dependend changes and all other kind of trash. Repo should contain only merged changes.
- Delete project’s folder, create new one and pull the latest repository (
- Create and checkout some technical or fixup branch (
git checkout -b xx-gerrit-is-stupid).
- Copy files from backup location (point 1) over current repository state.
- Commit all changes (
git add --all+
git commit -am "Merge changes rejected by Gerrit).
- Push them (
- Review and submit just pushed change (branch) in Gerrit UI.
As you can see, this is pretty much the same as previous rebasing. The only different is, that it works in 99% of situations, in which previous method failed. As you can also see, this isn’t a brute-force method that much. It doesn’t destroys much. You end up with up-to-date Gerrit repo, containing all your changes (no source code is lost) and with no stupid dependencies or other trash. The only side effect is, that you’re loosing a small bit of history and pushing all the changes (probably from more than one branch) in one, new, technical branch.
But, to be honest, that is something I can accept. Especially, if in exchange, I’m getting pretty clean Gerrit repo, purged with all the mess, in just a few minutes.