# Some Gerrit help/clarifications



## kaladin (Feb 17, 2013)

I see a lot of helpful tutorials for Git but not much for a few questions I have for Gerrit.

So I've created a Git server. Then installed Gerrit. I understand the flow/process with Gerrit vs using Git directly.
I've grabbed the git commit hook so the change ID get inserted automatically on commit.

So here come a few questions:
1. I'm a user. I've made changes and git pushed it to gerrit. It gets a change ID. Then I've done something else and that gets a second Change ID. So I have two "open" things. So my local repo is ahead by two commits. Now someone posted to gerrit that something needs to be fixed with the first thing. If i go ahead and make that change in my local repo and git commit and git push, do I have to manually ensure it has the same change ID so it shows up as patchset 2? When would I use git --amend as that would seem to only apply to my last commit...

2. I have a file I edited and git commit, git push, now its an open item in gerrit. I then had to remove a line in same file and re-edit some of the text I had previously added. Now that is patchset 2. Using gerrit to merge says the file has to be rebased? If you were using normal git, no gerrit, there is no conflict here as its just one file. But gerrit complains about it needing to be rebased all the time. 
I feel like I'm missing some easy workflow here to avoid this crap.

Also what if I am not the author? Someone else made these changes, I go into gerrit to click merge and it says they need to be rebased. What is my process to do that? I assume something like git fetch the change... but then rebasing never works for me or maybe I'm not typing /refs/head/master etc correctly to rebase...

I know there must be some masters of gerrit here from CM or AOKP, etc as I see the crazyness you guys checkin and deal with. Any pointers/clarifications to any of the above would be greatly appreciated.


----------



## JBirdVegas (Jun 11, 2011)

1) Users should start a new branch for each commit to a project. So lets say I have two sweet commits to project xyz

Change one:

```
<br />
cd project/xyz<br />
repo start mySweetFirstChange .<br />
#make magic happen<br />
git add -A // or any git add action<br />
git commit -m 'I fixed all the things'<br />
repo upload .<br />
```
Change two:

```
<br />
cd project xyz<br />
#close previous repo change<br />
repo abandon mySweetFirstChange .<br />
repo start mySweetSecondChange .<br />
#make magic happen<br />
git add -A<br />
git commit -m 'and some other stuff'<br />
repo upload .<br />
```
This should mediate most of your merge conflicts (if the files change the same code then you will have to fix manually and recommit)

2) Check that the history of the project matches the history Gerrit has for the project. When you start a branch with repo start it should be based of the latest merged code and build from there. Try either repo sync beforehand or git pull manually (You'll have to setup the remote via git remote add). Other than that not too sure why your seeing that.

3) If your not the author then you need to visit this command:


```
git commit --amend --author "HeyGuy <[email protected]>" -m "Stuff... about things"
```
** git commit --author "HeyGuy <[email protected]>" ** <--- All fields are required to edit author ie "Name Of New Author <[email protected]>"
#or modify your git add vs git commit -a vs git commit --amend as your needs suit you

Also to note on gerrit if you make a change then later after you abandon and move on then come back and visit a patch... Gerrit tracks patches to projects via there Change-Id so if you include the same Change-Id as your first patch set then automatically your second (newly submitted PatchSet with the same Change-Id) commit is automatically shown as PatchSet 2 of your original Change-Id.

tl;dr Gerrit is both fun and easy... once you stop tl;dr things 0
sorry I couldn't help but throw a new BadJokeException(";-)");


----------



## kaladin (Feb 17, 2013)

thanks, I'll test this out today with some garbage commits. 
Of the guides i can find that give a gerrit tutorial, more than a few use git-review. I hesitated to rely on something that really just wraps up the git commands you'd use anyway but it seems I could pass the -v option to it to see what it is doing and still learn.


----------



## JBirdVegas (Jun 11, 2011)

I didn't know about git-review. I wouldn't completely avoid the wrappers in face you can make your own 'aliases' and you may want to as some git commands can get quite lengthy.

Even the repo script has tons of features that are not well known. Recently I've seen lots of developers use the drafts upload to track changes the public can't see (admins can see drafts). Repo wrappers make it very simple: repo upload -d path/to/mystuff

Sure you could also use git and push to the corresponding head/revs/drafts (I don't think that's the actual head just example).

I guess its just a question of you CLI-foo


----------

