asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jianfeng Jia <>
Subject Re: git-gerrit updates
Date Mon, 12 Oct 2015 20:05:25 GMT
I have a chance to use this new -m option today. I really like it! 
One big benefit to me is that my local feature branch and remote one don't get diverged after
I update & submit the code review. I can comfortably use my github repo to work on the
different computer seamlessly. 

About the -b option, is it mandatory now? 
I’ve run “git gerrit update -b master” successfully. 
But if I just run “git gerrit update” without specify the branch name (which I was using
previously), it gives me the following error:

Updating local origin/varlen-string (should always succeed)...
Note: checking out 'origin/varlen-string'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 4721859... fix the ByteArrayParser's misleading names
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.

    git pull <remote> <branch>

Failed to update local origin/varlen-string! Resolve conflicts there...

It asks me to specify which branch I want to merge with. I just want to confirm that it is
the expected behavior and I’m not misunderstood the -b option. Thanks!

> On Sep 25, 2015, at 4:16 AM, Chris Hillery <> wrote:
> 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


Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message