Gerrit and development branches issues
aboytsov
I am new to Git and Gerrit and I apologize if my questions are silly.
I am considering using Gerrit as our Git server and a code review
system, and I am a little confused about how it works with development
branches. I wonder if you could help me figure it out:
1) How do we use Gerrit to enable developers have their own branch? I
have no problem creating a branch, working on it (locally) and pushing
for review, but as soon as I want to sync this branch with the central
Gerrit repository, I ran into trouble.
The most common use-case for this scenario is when a developer
works on a feature for several days, and doesn't want risking losing
his work in the process. So, he'd like his development branch and
history to be synced to Gerrit. He also might be changing machines, so
it would be handy for this purpose, too.
So, I gave Push Branch access to refs/heads/dev/* references. Now
every developer can create a branch like dev/feature and push code
changes there. The trouble starts when I want to create a code review
that merges their branch into the master.
When I try to push it:
git push origin HEAD:refs/for/master
it says there are no changes
I tried to amend it by:
git commit --amend
and then push it, which creates a code review, but I can't submit
it into the master because of the resulted conflict (as Gerrit UI
tells me). And as soon as I push this amended change to the Gerrit
server with
git push origin dev/feature
the review is automatically closed.
So, here's the question: given the master branch and the
development branch, how do I create a code review that contains the
changes committed to the development branch, and then merge these
changes to the master?
Or does Gerrit only works as long as you're making all your
changes locally?
2) Multiple commits. This is probably more of a Git question than
Gerrit question, but stil. As far as I understand if I made several
commits to my branch before pushing it for review, Gerrit will
automatically create several reviews for each of these commits.
Do I understand correctly that the way to fix that and have only
one review created is to use git rebase? I tried it and still have
some questions open:
- I need to squash commits, right? Is 'git rebase -i' the
only way to do it? I tried to find out how to squash commits
automatically without vim, but couldn't.
- How do I automatically find out the latest commit that was
reviewed and integrated into master to squash everything after it?
- Similarly, if this branch has never been merged yet, how
do I automatically find out the common ancestor between this branch
and the master to squash everything after it in one single commit?
3) Is there any other way to add people to the review from the command
line than the cumbersome:
git push --receive-pack='git receive-pack --reviewer=a...@a.com --
cc=b...@o.com' ...
4) Couldn't find a direct answer in the documentation. If I pushed the
code for the review, and then continued working on it, and made some
other changes, if I push it again, my understanding is that it will
create another review (or more, one for each commit). But how do I
incorporate these changes into the existing review?
5) Initially I thought that once the change is approved, anybody or at
least the author can merge the change to the master and push the
master to Git. Now my understanding is that master is sacred and
without the right access no one can mess with it, and the only way
merge changes is clicking on "Submit" button in the UI. It seems a bit
awkward, is my understanding correct?
6) Is there a way to ignore Verify status and allow submits with +2
Review only without removing the Verify attribute from the database,
as the documentation suggests? I'm not sure I will be able to recover
it when we start using it.
7) Somewhat unrelated. I set up LDAP and Gerrit calls us all Anonymous
Cowards without letting us to edit our full names in the UI. Does it
mean we don't have full names in LDAP? Why wouldn't it let us edit it
in Gerrit?
Sorry for the long email, and thank you so very much!
Artem.
Swindells, Thomas
Thomas
[Swindells, Thomas] I think you'd switch to your local copy of the master branch
and do a git pull <your diverged branch> to pull in the changes and merge it into master.
Another option is probably to just rebase your changes onto origin/master.
> Or does Gerrit only works as long as you're making all your changes
> locally?
>
> 2) Multiple commits. This is probably more of a Git question than Gerrit
> question, but stil. As far as I understand if I made several commits to my
> branch before pushing it for review, Gerrit will automatically create several
> reviews for each of these commits.
>
> Do I understand correctly that the way to fix that and have only one
> review created is to use git rebase? I tried it and still have some questions
> open:
> - I need to squash commits, right? Is 'git rebase -i' the only way to do it? I
> tried to find out how to squash commits automatically without vim, but
> couldn't.
> - How do I automatically find out the latest commit that was reviewed
> and integrated into master to squash everything after it?
> - Similarly, if this branch has never been merged yet, how do I
> automatically find out the common ancestor between this branch and the
> master to squash everything after it in one single commit?
[Swindells, Thomas] you'd normally do 'git rebase -i origin/master' this makes sure
your commit is against the tip of master (make sure you fetch first). Sometimes it
may be better to squash your commits before rebasing (particularly if later commits
fix merge issues that an earlier commit would have) other than using git log to manually
do it I've not worked out if there is an easy git command to rebase all local changes
without rebasing where the first commit is branching from.
> 3) Is there any other way to add people to the review from the command
> line than the cumbersome:
>
> git push --receive-pack='git receive-pack --reviewer=a...@a.com --
> cc=b...@o.com' ...
[Swindells, Thomas] Just do it in the UI. Or encourage people to subscribe to be
notified when changes are pushed and pull doing the reviews themselves.
> 4) Couldn't find a direct answer in the documentation. If I pushed the code
> for the review, and then continued working on it, and made some other
> changes, if I push it again, my understanding is that it will create another
> review (or more, one for each commit). But how do I incorporate these
> changes into the existing review?
[Swindells, Thomas] Either do git commit --amend or squash it with a rebase.
Read up on the section on change-ids as that is what controls whether it is treated
as a new commit or a new patchset to an exist commit.
>
> 5) Initially I thought that once the change is approved, anybody or at least the
> author can merge the change to the master and push the master to Git. Now
> my understanding is that master is sacred and without the right access no
> one can mess with it, and the only way merge changes is clicking on "Submit"
> button in the UI. It seems a bit awkward, is my understanding correct?
[Swindells, Thomas] Yeh, though I can't say I've ever found it overly awkward
or time consuming. Depending on how you want to work it can be either the
committer or the reviewer who presses submit.
> 6) Is there a way to ignore Verify status and allow submits with +2 Review
> only without removing the Verify attribute from the database, as the
> documentation suggests? I'm not sure I will be able to recover it when we
> start using it.
[Swindells, Thomas] If you are planning to use it in the future then just encourage
people to do a manual verification and set the flag themselves - either the reviewers
or the original committer just before they merge.
> 7) Somewhat unrelated. I set up LDAP and Gerrit calls us all Anonymous
> Cowards without letting us to edit our full names in the UI. Does it mean we
> don't have full names in LDAP? Why wouldn't it let us edit it in Gerrit?
[Swindells, Thomas] As you say it sounds like you don't have fullnames in LDAP, or at least
not under the field that Gerrit is expecting.
> Sorry for the long email, and thank you so very much!
>
> Artem.
>
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
Magnus Bäck
aboytsov <aboy...@gmail.com> wrote:
> 1) How do we use Gerrit to enable developers have their own branch? I
> have no problem creating a branch, working on it (locally) and pushing
> for review, but as soon as I want to sync this branch with the central
> Gerrit repository, I ran into trouble.
> The most common use-case for this scenario is when a developer
> works on a feature for several days, and doesn't want risking losing
> his work in the process. So, he'd like his development branch and
> history to be synced to Gerrit. He also might be changing machines, so
> it would be handy for this purpose, too.
> So, I gave Push Branch access to refs/heads/dev/* references. Now
> every developer can create a branch like dev/feature and push code
> changes there. The trouble starts when I want to create a code review
> that merges their branch into the master.
> When I try to push it:
> git push origin HEAD:refs/for/master
> it says there are no changes
Indeed, the commits you're trying to push are already known by Gerrit.
You can't review the exact same commit multiple times.
> I tried to amend it by:
> git commit --amend
> and then push it, which creates a code review, but I can't submit
> it into the master because of the resulted conflict (as Gerrit UI
> tells me).
Yeah, but that's unrelated to your workflow. Your commit just needs to
be rebased.
> And as soon as I push this amended change to the Gerrit server with
> git push origin dev/feature
> the review is automatically closed.
Yes, because they have the same change id. On the other hand, why would
you want to keep the dev/feature commit open after having merged the
"real" commit?
> So, here's the question: given the master branch and the
> development branch, how do I create a code review that contains the
> changes committed to the development branch, and then merge these
> changes to the master?
Three options for you:
* Merge dev/feature into the master branch. In other words, review
and submit the changes to dev/feature, then create a merge commit
that you upload to the master branch.
git merge origin/dev/feature
git push origin HEAD:refs/for/master
* As suggested by Thomas, reupload all changes to the master branch
(probably changing the change-id while you're at it).
* Why not have the developers upload the changes straight to the
master branch, if that's indeed where they're headed anyway?
> Or does Gerrit only works as long as you're making all your
> changes locally?
Sorry, I don't understand this question.
> 2) Multiple commits. This is probably more of a Git question than
> Gerrit question, but stil. As far as I understand if I made several
> commits to my branch before pushing it for review, Gerrit will
> automatically create several reviews for each of these commits.
Yes.
> Do I understand correctly that the way to fix that and have only
> one review created is to use git rebase? I tried it and still have
> some questions open:
> - I need to squash commits, right? Is 'git rebase -i' the
> only way to do it? I tried to find out how to squash commits
> automatically without vim, but couldn't.
You could use the --squash option to "git merge".
If you constantly find yourself with topic branches with many commits
that you want to squash to a single one, perhaps you should think about
how you work with Git. Should you perhaps use "git commit --amend" to a
greater extent to avoid creating such an excessive amount of commits? Or
are the commits generally of the right size and you just have a bad
habit of wanting to squash unrelated changes? I have no idea, but I'd
say that a common beginner's mistake is to squash too much, creating
commits that are unbearable to review and understand afterwards.
> - How do I automatically find out the latest commit that was
> reviewed and integrated into master to squash everything after it?
origin/master points to the upstream master branch, or rather our
current notion of where the upstream master branch is. Run "git fetch"
to download new data and possibly update the branch head.
> - Similarly, if this branch has never been merged yet, how
> do I automatically find out the common ancestor between this branch
> and the master to squash everything after it in one single commit?
You can use "git merge-base commit1 commit2" to find the most recent
common ancestor between two commits, but the tools we're talking about
here (rebase and merge) will do this for you.
> 3) Is there any other way to add people to the review from the command
> line than the cumbersome:
>
> git push --receive-pack='git receive-pack --reviewer=a...@a.com --
> cc=b...@o.com' ...
Repo makes it easier, but with plain Git this is as simple as it gets.
> 4) Couldn't find a direct answer in the documentation. If I pushed the
> code for the review, and then continued working on it, and made some
> other changes, if I push it again, my understanding is that it will
> create another review (or more, one for each commit). But how do I
> incorporate these changes into the existing review?
If you have a Change-Id line in the commit message you'll automatically
upload a new patch set when you push the amended commit. If not you'll
have to push to refs/changes/<change number> rather than to
refs/for/branchname.
> 5) Initially I thought that once the change is approved, anybody or
> at least the author can merge the change to the master and push the
> master to Git. Now my understanding is that master is sacred and
> without the right access no one can mess with it, and the only way
> merge changes is clicking on "Submit" button in the UI. It seems a
> bit awkward, is my understanding correct?
Not sure I understand. The workflow for *all* changes is
upload -> review & verify -> submit
and from Gerrit's point of view there's nothing special about the master
branch. By default I believe any registered user can submit any change
(given sufficient scoring of the change). If you don't want to submit
via the web UI, the "review" SSH command has a --submit option that can
be used to submit changes.
[...]
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
Artem Boytsov
* As suggested by Thomas, reupload all changes to the master branch
(probably changing the change-id while you're at it).
* Why not have the developers upload the changes straight to the
master branch, if that's indeed where they're headed anyway?
Sorry, I don't understand this question.
> Or does Gerrit only works as long as you're making all your
> changes locally?
Yes.
> 2) Multiple commits. This is probably more of a Git question than
> Gerrit question, but stil. As far as I understand if I made several
> commits to my branch before pushing it for review, Gerrit will
> automatically create several reviews for each of these commits.
You could use the --squash option to "git merge".
> Do I understand correctly that the way to fix that and have only
> one review created is to use git rebase? I tried it and still have
> some questions open:
> - I need to squash commits, right? Is 'git rebase -i' the
> only way to do it? I tried to find out how to squash commits
> automatically without vim, but couldn't.
If you constantly find yourself with topic branches with many commits
that you want to squash to a single one, perhaps you should think about
how you work with Git.
Magnus Bäck
Artem Boytsov <aboy...@gmail.com> wrote:
> On Fri, May 27, 2011 at 9:09 AM, Magnus Bäck
> <magnu...@sonyericsson.com>wrote:
>
> > * As suggested by Thomas, reupload all changes to the master
> > branch (probably changing the change-id while you're at it).
> >
> > * Why not have the developers upload the changes straight to the
> > master branch, if that's indeed where they're headed anyway?
>
> Imagine you're working on some very experimental feature. You're
> doing a bunch of stuff with the code, rewriting some parts of it,
> reorganizing it, lots of changes that will end up being thrown away,
> etc. Try that, try this. You don't want all that temporary stuff to
> go into master. You could do it all locally of course, but what about
> backups and being able to switch machines? You probably don't want
> some engineer to have to review your code in junk-state which you
> want to push to the server before you switch machines.
>
> So you need some kind of a temporary branch free from review
> requirements where you do all your bashing, and then once you've done
> you'll create a code review by squashing all your commits (I guess).
Why would some engineer review your code if it's destined for the master
branch but not when it's destined for some other branch? I guess it
could happen if the reviewers monitor changes uploaded for the master
branch, but I'd say the usual workflow with Gerrit is that you add
reviewers as necessary when you're ready to have your changes reviewed.
What we typically do with complex features is create a server-side
branch to which commits are uploaded and submitted (after reviewing).
When the feature is done we either merge it to the destination branch
(i.e. upload a merge commit as described earlier) or, if necessary,
rework the branch and upload a new set of commits.
> > You could use the --squash option to "git merge".
>
> I'm a bit confused. I thought git merge is what you do _after_ review,
> and you send changes for review with 'git push'.
Why would you run "git merge" after the review?
> So how would that help? Let's say I have a branch called 'feature'
> with 2 commits. I want to now merge it into 'master' with only one
> code review. If I do:
>
> git checkout feature
> git push origin HEAD:refs/for/master
>
> it will generate 2 reviews.
>
> So, what do I do instead?
Create a new branch based on the upstream master branch:
git checkout -b feature2 origin/master
Do a squash merge of the original topic to get a single commit
containing the changes from all commits present on 'feature' but
not on 'feature2':
git merge --squash feature
Push the single commit to Gerrit:
git push origin feature2:refs/for/master
> > If you constantly find yourself with topic branches with many
> > commits that you want to squash to a single one, perhaps you
> > should think about how you work with Git.
>
> It's very possible, please see the scenario I described earlier.
> Also, I thought the beauty of Git is partly because branching is
> so cheap. And cheap branching is good because it allows you to
> create an area where you can commit freely. It seems to me that
> if every commit has to be a complete, conceptual, clean change,
> there's not much benefit from cheap branching.
>
> What do you think?
Eventually every commit should be a complete and clean change, but the
road there isn't necessarily straight. One of the things I love about
Git is that you have the option of committing at any time and rearrange
and clean up commits later on. However, such cleanups in my experience
rarely consist of squashing branches completely. Squashing topic
branches with multiple commits is often a sign of someone who's
forgotten about the --amend option or has an unsound notion of how big
a commit should be.