Getting Your Commit Through Review

Even *experienced* programmers can get caught up with the GIT Gerrit system. Many have difficulty getting their code to build in Jenkins, have dependencies, or merge conflicts that prevent even beautiful code from being human reviewed never mind merging.

This page has been imported from http://www.oscarmanual.org and has not yet been reviewed by OSCAR EMR.

TIPS

It has to Build

... not just locally. Each pushed commit going in on the Gerrit side and is built by Jenkins in the default environment. If it doesn't build it can't be merged and no human will even glance at it. You can determine the build errors (both compiler, and unit tests) by following the link provided for your failed build back to Jenkins and look at the console link for that build. Its usually quickest to scroll up from the bottom of the console display to review your errors.

It has to lack Merge Conflicts

What can we say. If in the time between you cloned a local version of the repository, and the time that you push the commit someone else has merged in a newer version of code those two codes are in conflict.

Luckily finding and resolving these merges is easy with Eclipse. You then do Team > Merge or Team > Rebase and you can set the fast-forward, squash or no commit merge options in the dialog. You will usually pick fast-forward. If you are already up to date you will be told so or fast forwarded, but then you would not be reading this. The conflict result then labels the conflicts in the Staging View (which only shows modified files). The conflicts also show in Project explorer views. The content of the files are presented with in line textual conflict markers to indicate the differences in conflict. Use the Team > Merge Tool and use HEAD the last local version of conflicting files. The merge editor will open . Edit until peace and then Team > Add to mark that conflict as resolved.

It won't merge if it has outstanding Dependencies

We are finding that many new to Gerrit are making serial commits. When you do that without changing the pointer, the commits end up depending on each other in GIT (that is you keep building a local branch of your own). When that happens if ANY fail then NONE of the commits along your local branch can be merged into source which is a waste of effort. Unless the commits truly are dependent in code, it is better to reset your machine to the current head of the remote branch (merging in your changes) before making subsequent commits. (Team -> Reset -> Remote Tracking -> <branch eg origin/master>)

If they are dependent in code then it is better to squash the commits

Pull and Pull again

Even after your changes are merged on the central repository (you will get notifications by email) you must pull (or sequentially fetch and merge) again before you and the central repository are in sync (yes even if the files happen to be the same on the 2 servers, the pointers are not in sync until you merge with the pull).

When to commit locally and when to push remotely

Generally speaking you should commit locally for independent small units of work. So as an example if you are working on a feature, you may have incremental phases in completion of that feature. You should commit at each phase, the code should at least compile and run.

Generally speaking pushing remotely can be done for any commit. There is generally no need to bundle up multiple commits into one big push. The difference between a push and commit maybe more important if you're working offline as you can only push while online.

The reason for the above is because of the review model of Gerrit. You don't want to do one big commit because it will be a nightmare to review and approve. Think about the example of converting 300 DBHandler calls into maybe 100 JPA objects. If that was 1 commit, it would take for ever to review and verify that commit. If you made 300 separate commits, the review process could at least proceed incrementally and in manageable size chunks. The push is for a similar reason, if you had 300 separate commits and you pushed all at once at the end of 6 months, there will be a sudden flood of 300 commits to review and it would be a huge backlog. If you pushed those 300 commits over a 6 month period, review of the commits could have started as soon as the first push was done.

Remember to Commit to Master

Yes everyone wants their fix or feature in right now, for immediate use. We have a branch for that. However the next version is NOT coming from the branch but always from master. You must always commit (or cherry pick) to master or your work will be lost in time. You can cherry pick from the history view of Eclipse. Resolve your conflicts with the staging view.

Resources

eGit documentation https://wiki.eclipse.org/EGit/User_Guide