4 ms·

All of the problems you mention are completely, 100% solved: https://m.mediawiki.org/wiki/Gerrit/git-review https://m.mediawiki.org/wiki/Gerrit/git-review You

• liveoneggs 11y ago
  git review to submit, git review -d branch to review.. too bad the ux is so bad
  • pekk 11y ago
    If this is all that's wrong with the UX, why not write two tiny one-line scripts called gerrit-submit and gerrit-review?
    • deleted 11y ago
      [deleted]
  • zb 11y ago
    I think you might be confused... (and if not then I certainly am). The -d flag means 'download', and the argument isn't a branch name, it's the review number from the Gerrit URL. You don't use it for reviewing code (that generally happens in the Gerrit web interface, or in gertty), you use it when you want to modify a patch submitted by somebody else. I'm not sure what a UX that lets you check out somebody else's patch without specifying which patch would look like. FWIW I use Gerrit every day, and I don't recall ever once using the -d flag.
• kazinator 11y ago
  The problem is that it doesn't just solve the couple of minor annoyances, but provides a whole new ball of wax. I don't want to work with anything that automatically creates, switches or deletes branches. I happily work with Gerrit using nothing but the regular integration branch: very simple. If I have several independent changes, I just keep them in that same branch as if they were dependent. This does generate some nuisance rebases in Gerrit, but these are not worth the hassle of separating the changes to different branches. If I happen to have a large number of independent changes, what I can do to avoid overwhelming the review system is to not push all of them at once. I can do a "git rebase -i" to re-order the changes in the order in which I would like them approved (say by urgency of the issues to which they are attached). Then, piecemeal, I can push these out to Gerrit, say two or three at a time. When those are approved, push the next batch and so on. This keeps most of the "false dependency rebasing" local to me, not bothering the reviewers. Gerrit requiring a somewhat better than casual familiarity with git is a good thing; by requiring it, it thereby promotes better familiarity, which makes developers more productive in the use of their version control system outside of the Gerrit context also. The Change-ID handling is a very minor thing. When making a first commit, I just do ":r!change-id" in Vim, and it reads in the output of my change-id script: a brand new Change-ID: line with a shiny new change ID. My Git commit message template contains a blurb which reminds me to do this. We have a required bug number field also, so this just goes hand-in-hand with that.
  • zb 11y ago
    I have created literally thousands of reviews with git-review, and I have never once used it to create, switch or delete a branch. When I clone a new repo, I run "git review -s" (for setup), which installs the commit hook that ensures I never need to give even a passing thought to Change-IDs. Then I run "git review" to push changes to review. I never have to think about where I'm pushing them because it's all configured in the .gitreview file. I generally also keep all my changes in a single branch (although I also use Stacked Git to cut down on unnecessary dependencies, and because I like it a lot better than "git rebase -i" for many purposes). That's it. I've heard there are other flags. I've never used them. Nobody is forcing you. But by all means carry on generating Change-IDs manually if you like.