5

Pushing changes to Gerrit requires the rather esoteric command

git push origin HEAD:refs/for/branchname

We've scripted this, but I'm looking for a way to do this natively. With git's powerful config, it looks like I can preconfigure most of it[1] so that just git push suffices... almost. I'm stuck on the remote.<name>.push refspec.

I can already create a tracking topic branch so that git pull (no other parameters) will pull changes from upstream remote into my topic branch. However with Gerrit, the push and fetch refspecs aren't the same: one fetches (merges) from refs/heads/trackbranch, but one pushes to refs/for/trackbranch[2]

I can configure a push refspec in remote.<name>.push, however the syntax is pretty basic: if I put push = refs/heads/*:refs/for/*

Then that will try pushing my t-foo topic branch to refs/for/t-foo. But git has the information that t-foo is tracking trackbranch. Can I define a refspec so that git automatically tries to push any t-foo to its refs/for/trackbranch ?

We're currently using a script to do this, and I suppose I could define a push refspec for each topic branch (possibly through more scripting). I'm hoping there's a native git way of doing this so that we don't need to rely on more custom in-house scripts for our team.

[1] by defining a tracking branch with git checkout origin/upstream_branch -b topic_branch or within an existing branch git branch --set-upstream-to origin/upstream_branch

[2] pushing to refs/for/* creates a changeset for review. With appropriate permissions, one could push to refs/heads/* to bypass review, but that negates most of the point of Gerrit.

John de Largentaye
  • 893
  • 4
  • 19
  • "Can I define a refspec so that git automatically tries to push any t-foo to its refs/for/trackbranch?" No, at least I don't think so today. What you want to get at is the `fetch=...` mapping machinery git uses with merge names (to map the `remote=` and `merge=` parts) and that doesn't seem to be exposed anywhere. You could write a program that munches through your set of local branches and computes all this, though (then updates your gitconfig). Still a bit painful either way. – torek Feb 21 '14 at 23:10
  • Yeah, that's what I wish to do. If this is confirmed, why not put it as an answer? – John de Largentaye Feb 21 '14 at 23:21
  • 1
    After more searching, my question is similar to http://stackoverflow.com/questions/7101145/how-to-configure-specific-upstream-push-refspec-for-git-when-used-with-gerrit from two years ago and http://stackoverflow.com/questions/14320363/push-current-branch-to-gerrit from last year – John de Largentaye Feb 21 '14 at 23:47

2 Answers2

2

For some reason :-) I went ahead and tried to write a script to set git config entries, and then found that there seems to be no way to get the desired results directly.

As an alternative, I wrote a script that pushes to the "gerrit review name" (note: I have not actually used gerrit so this is essentially untested, though I've run it with the --dry-run option and it looks like it Does The Right Thing—but I expect you might want to modify it). Of course this is probably functionally the same as your own script.

Anyway, you could then have a global or system-wide alias, git config alias.review or some such, that runs the script, so that you could say git review or git review branch. The alias would just be review = !sh /path/to/script (arguments will get passed on automatically at this point).

I put the script up here: http://web.torek.net/torek/git/gerrit-review.sh.txt (the .txt extension is just so that browsers view it by default, rather than downloading it by default).

torek
  • 448,244
  • 59
  • 642
  • 775
1

Have you looked into the git-review plugin? It should fit the bill quite happily!

https://pypi.python.org/pypi/git-review

gepoch
  • 711
  • 6
  • 17
  • I haven't and it looks interesting, but it's still an extra script rather than using git's extensive native features (we've already shifted from using our home-grown "topic branch" tagging in favor of git's "tracking" feature). It's frustrating because it looks like almost everything's there, except this last link in the chain. – John de Largentaye Feb 21 '14 at 23:04
  • I see what you mean, but consider that git once had almost no native features around version control. It is, at its heart, a content addressable filesystem. Everything else grew around it as little add-on scripts which eventually were ported into C for speed. git-review is as "native" as anything else, in a sense... – gepoch Feb 24 '14 at 16:03