Gerrit Tips and Tricks

[Anush Elangovan(அனுஷ்)]

Before you read the Tips: We want developer help to update
documentation on dev.chromium.org. So please fix anything you see is
appropriate especially remove references to "git cl" and friends.

1) Remember your ChangeId is how repo/gerrit knows if the CL is new or
not. The ChangeId has to be in the last paragraph. (See
http://gerrit.chromium.org/gerrit/Documentation/user-changeid.html)

2) Once you repo upload a change repo sync will not rebase the change
automatically and will warn you. You will have to "repo rebase -i" to
rebase your change to "top of tree" if the top of tree has moved since
your last sync
(See http://groups.google.com/group/repo-discuss/web/repo-gerrit-git-workflow)

3) Using git push to create changes in Gerrit (NOTE:Only for Projects
not in the repo manifest or special branches e.g: manifest.git or
manifest-internal.git)

git push ssh://sshusername@hostname:29418/projectname HEAD:refs/for/branchname
(See http://gerrit.chromium.org/gerrit/Documentation/user-upload.html)

4) Merge if CL applies cleanly. (We are experimenting with using allowing
a change to go in if it merges cleanly). This prevents unnecessary
rebases in fast moving repos like chromiumos-overlay.git (sidenote: we
are trying to move autogenerated code to another repo).
There is a concern of commits showing up as merges, but you can still
find the original commit so it may be ok. This can be turned on/off on
a per project basis. Ideas/Comments/Bikeshedding welcome :)

Please update documentation and email links to any tips you have to share.

[Antoine Labour]

I disagree, especially for fast-moving repo that everybody touches, like chromiumos-overlay, because merges make bisecting becomes very hard (non-linear history).

Antoine

 

Please update documentation and email links to any tips you have to share.

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Olof Johansson]

On Wed, May 4, 2011 at 11:14 AM, Antoine Labour <pi...@chromium.org> wrote:

On Wed, May 4, 2011 at 10:26 AM, Anush Elangovan(அனுஷ்) <an...@chromium.org> wrote:

4) Merge if CL applies cleanly. (We are experimenting with using allowing
a change to go in if it merges cleanly). This prevents unnecessary
rebases in fast moving repos like chromiumos-overlay.git (sidenote: we
are trying to move autogenerated code to another repo).
There is a concern of commits showing up as merges, but you can still
find the original commit so it may be ok. This can be turned on/off on
a per project basis. Ideas/Comments/Bikeshedding welcome :)

I disagree, especially for fast-moving repo that everybody touches, like chromiumos-overlay, because merges make bisecting becomes very hard (non-linear history).

There's another mode: cherry-pick if it can be done cleanly. It should result in a clean linear commit history with similar trade-offs to the merge option. We're trying it on the kernel repos right now, we'll see how well it works in reality.

-Olof

[Anush Elangovan(அனுஷ்)]

Olof - Once you report back on the success of it, I can switch it to
using cherry-pick.

Anush

>
>
> -Olof

[Olof Johansson]

Looks like it's working pretty well so far. It would mostly fall apart if there are changes to the same files, and we haven't had much of that in the kernel so far.

Try it and see how it holds up? Do any other gerrit users have feedback on it per chance?

-Olof

[Antoine Labour]

Definitely let's go for it. If it merges cleanly it should cherry-pick cleanly, so there's no good reason it would create additional failures.

See the current state of chromiumos-overlay (in attachment). It's only been a couple of days.

Antoine

[Anush Elangovan(அனுஷ்)]

Ok cherry-pick it is. Let me know if you run into any problems.