I've pushed a couple updates to git-gerrit which might be of interest to folks using it.
First, I added a "git gerrit update -m" option, which will attempt to update your local branch by doing "git merge" rather than "git rebase". Based on the discussion lately, it seems like this may enable a little more flexibility in dealing with sharing branches and handling squashed commits. It should be more forgiving of finding duplicate changes, especially when some of those changes are squashed, because "git merge" views the merge holistically rather than a commit at a time. Fair warning: It will introduce merge commits on your branch, which can look weird and be harder to follow. And if you submit a change through Gerrit and then "git gerrit update -m" to continue working on the same branch, you'll see all your older local changes AND the squashed Gerrit commit in your history. This isn't necessarily fatal - "git gerrit submit" will still squash everything, so this noise only affects your local branch and not the eventual commit to master. And as I said it may be handy when you've shared a branch from someone else, or something like that. Still, the rebase solution is neater when it works, so it is still the default behaviour for "git gerrit update". The second change I added to git-gerrit probably won't affect any of you, but it's been driving me bonkers for a while. "git gerrit update" and "git gerrit submit" have a -b option which is used when you are working on a feature branch off of an upstream branch other than "master". I constantly forgot to specify "-b upstream" to those, which led to all sorts of ugly side-effects. Now git-gerrit is smart enough to default to the tracking branch for your local branch, instead of always assuming "master". Ceej aka Chris Hillery
