Re: git-gerrit updates

[Jianfeng Jia <ji...@gmail.com>]

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 <ch...@hillery.land> 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



Best,

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

Re: git-gerrit updates

[Chris Hillery <ch...@hillery.land>]

The -b option is still optional. The change I made recently only changed
the default value: previously it was hardcoded "master"; now it will be the
upstream branch that the current branch is tracking, or "master" if there
is none.

However, it DOES assume that the upstream tracking branch is another local
branch, and that that local branch has the same name as the Gerrit branch
you want to submit to (just like it previously assumed that "master" was a
local branch, and that you want to submit to the Gerrit branch "master").
In other words, my change lets it work a bit better with projects that have
multiple branches in Gerrit.

In your case, it looks like you had a local branch that was set to track
"origin/varlen-string", which isn't a local branch, which is why it got
confused. I should probably put in some additional error-checking to detect
that and provide a better error message.

If your project does have a "varlen-string" branch in Gerrit, then I can
tell you how to update your local git repo to work with that. If
"varlen-string" is just a feature branch, however, and you want to propose
the change to master in Gerrit, then you should either use "git gerrit
update -b master" or set the upstream tracking branch for your local branch
to "master" with "git branch --set-upstream-to=master".

If you want to have your upstream set to a remote feature branch (eg.,
"origin/varlen-string") AND still propose to Gerrit master, then I think
you'll need to remember to use "-b master" now for "git gerrit update" and
"git gerrit submit", which isn't ideal. That's not a use case I'd
considered. Perhaps we could talk on Skype at some point about what you'd
like to happen here.

Ceej
aka Chris Hillery

On Mon, Oct 12, 2015 at 1:05 PM, Jianfeng Jia <ji...@gmail.com>
wrote:

> 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 <ch...@hillery.land> 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
>
>
>
>
> Best,
>
> Jianfeng Jia
> PhD Candidate of Computer Science
> University of California, Irvine
>
>