Hey, lazyweb! My google-foo may be weak today.

With Gerrit, is there a way (ootb or with a plugin) to configure it so that when a changeset to (say) refs/for/master is approved, that the resulting commit shows up not only on refs/heads/master but also refs/heads/otherbranch (assuming that it is a fast forward merge for otherbranch)?

(Use case: Developers want generic branch names that are identical across many repositories so that they don’t have to keep stopping to ask themselves which branch they should be working on for this repository; to avoid hysteresis, production processes depend on branch names having additional semantic content generally irrelevant to developers, but the production processes never commit.)

Eugene Crosser August 12, 2014 06:07

I have no experience with gerrit, put perhaps this can be done with git alone. I have post-receive hooks to mirror my repos to github after changes are pushed there:

unset $(git rev-parse –local-env-vars)

git –git-dir ~/pdns-pipe-nmc.git push –mirror \

        git@github.com:crosser/pdns-pipe-nmc.git

maybe similar approach could work to merge updates into other branches of the same repo. You would probably want to use post-update hook, and do something like

git checkout other-branch && git merge –ff-only source-branch

or some clever rebase like

git rebase –onto other-branch source-branch other-branch

(the commands are untested and probably wrong, just to show the idea).

Michael K Johnson August 12, 2014 06:49

Can’t use git checkout on a bare repository.

I expect it wouldn’t be that hard to add a Gerrit extension to implement what I want; it would just be silly to implement it if it already exists and my google-foo was weak. The equivalent of “git push remote genericbranch:otherbranch” would be enough. In fact, it might be a really good thing not to see “otherbranch” in Gerrit to avoid confusion when new developers join a team.

The problem with git post-receive has to do with additional constraints I didn’t mention: The Git server is centrally-managed gitolite with thousands of repositories, but the Gerrit is multiple team-administered instances, and the teams would be the ones managing the branch mappings in a few repositories (up to several dozens). Everyone (teams and central admins) will be happier if this is self-service. ☺

For what it’s worth, this is a case where in the post-receive I would use update-ref, and I don’t need to deal with the question of a ff merge or not because I actually don’t want to merge; the reference would act more like a tag that moves than like a classic branch, and moving it to a non-ancestor would not abandon commits because it would only shadow other branches. For that reason, it would really be “git push –force remote genericbranch:otherbranch” in my hypothetical Gerrit extension. Except that it would be whatever the equivalent would be driving JGit from the API, rather than git from the command line. Since I’m not a Java developer, I get all hand-wavy here.

As an aside, Gerrit uses “extension” and “plugin” exactly backwards from what I expect. I’d expect an “extension” to be tightly bound to implementation details that it extends, and I’d expect a “plugin” to plug into a generic stable interface. But in Gerrit, an “extension” is what plugs into the stable interface and a “plugin” is what extends internals that may change from version to version. Oh, well.

Imported from Google+ — content and formatting may not be reliable