| commit | cf38c03d941576c7a6c41cbe9713b0289ca6999d | [log] [tgz] |
|---|---|---|
| author | Dave Borowitz <dborowitz@google.com> | Mon May 02 11:06:23 2016 -0400 |
| committer | Dave Borowitz <dborowitz@google.com> | Mon May 02 11:20:28 2016 -0400 |
| tree | 2d5ef39cbd8722b941524ed4a308ceeab542dfa8 | |
| parent | e38fee58f7a74e68798741dde610d0eb350e6eeb [diff] |
Use google-java-format for styling google-java-format is an open-source tool[1] for mechanically converting Java code to follow the Google Java Style Guide[2] formatting recommendations. The tool is inspired in part by gofmt[3], which has been very successful in the Go community. Any automatic formatter is going to make some decisions that not everyone agrees with, but the goal is to avoid pointless discussions in reviews that detract from actually understanding the code. My personal experience with this tool is that it adds many more newlines than I would write in my own code, leading to deeper indentation. It took me a while to get used to it, but I'm fine with it now. (It's worth pointing out that the deeper indentation is also more bearable because Gitiles uses a 100-column limit; for an 80-column limit it might be less readable.) Converting all at once like this definitely hurts blame-ability, but honestly at this point in Gitiles most of the lines were written once, by me, so we're not losing too much. [1] https://github.com/google/google-java-format [2] https://google.github.io/styleguide/javaguide.html [3] https://blog.golang.org/go-fmt-your-code Change-Id: I289c5ea97f416b9b709db1033bdb8357fdaa9690
Gitiles is a simple repository browser for Git repositories, built on JGit. Its guiding principle is simplicity: it has no formal access controls, no write access, no fancy Javascript, etc.
Gitiles requires Buck to build.
sudo apt-get install ant
cd ${HOME}
git clone https://github.com/facebook/buck.git
cd buck
ant
sudo ln -s ${PWD}/bin/buck /usr/bin/buck
cd /path/to/gitiles
git submodule update --init
buck build all
buck test
cd /path/to/repositories # Don't run from the gitiles repo. /path/to/gitiles/tools/run_dev.sh
This will recompile and start a development server. Open http://localhost:8080/ to view your local copy of gitiles, which will serve any repositories under /path/to/repositories.
To run unit tests, run buck test.
If you'd like to use Eclipse to edit Gitiles, first generate a project file:
./bucklets/tools/eclipse.py --src
Import the project in Eclipse:
File -> Import -> Existing Projects into Workpace
The project only needs to be rebuilt if the source roots or third-party libraries have changed. For best results, ensure the project is closed in Eclipse before rebuilding.
Java code in Gitiles follows the [Google Java Style Guide] (https://google.github.io/styleguide/javaguide.html) with a 100-column limit.
CSS in Gitiles follows the [SUIT CSS naming conventions] (https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md).
Gitiles uses Gerrit for code review: https://gerrit-review.googlesource.com/
Gitiles uses the “git push” workflow with server https://gerrit.googlesource.com/gitiles. You will need a generated cookie.
Gerrit depends on “Change-Id” annotations in your commit message. If you try to push a commit without one, it will explain how to install the proper git-hook:
curl -Lo `git rev-parse --git-dir`/hooks/commit-msg \
https://gerrit-review.googlesource.com/tools/hooks/commit-msg
chmod +x `git rev-parse --git-dir`/hooks/commit-msg
Before you create your local commit (which you'll push to Gerrit) you will need to set your email to match your Gerrit account:
git config --local --add user.email foo@bar.com
Normally you will create code reviews by pushing for master:
git push origin HEAD:refs/for/master