Edit for the theme Ambiance (for example):
- /usr/share/themes/Ambiance/gtk-3.0/settings.ini
- /usr/share/themes/Ambiance/gtk-3.0/gtk.css
- /usr/share/themes/Ambiance/gtk-2.0/gtkrc
- #000000 – tooltip_bg_color
- #f5f5b5 – tooltip_fg_color
Rudger Gravestein
Edit for the theme Ambiance (for example):
Gerrit Batch Abandon
http://phabricator.com/docs/phabricator/article/Recommendations_on_Revision_Control.html
Defined | src/docs/flavortext/recommendations_on_revision_control.diviner:1 |
---|---|
Group | Flavor Text |
Project recommendations on how to organize revision control.
This document is purely advisory. Phabricator works with a variety of revision control strategies, and diverging from the recommendations in this document will not impact your ability to use it for code review and management.
This is my (epriestley’s) personal take on the issue and not necessarily representative of the views of the Phabricator team as a whole.
There are a few ways to use SVN, a few ways to use Mercurial, and many many many ways to use Git. Particularly with Git, every project does things differently, and all these approaches are valid for small projects. When projects scale, strategies which enforce one idea is one commit are better.
Choose a strategy where one idea is one commit in the authoritative master/remote version of the repository. Specifically, this means that an entire conceptual changeset (“add a foo widget”) is represented in the remote as exactly one commit (in some form), not a sequence of checkpoint commits.
A strategy where one idea is one commit has no real advantage over any other strategy until your repository hits a velocity where it becomes critical. In particular:
Continue reading “Recommendations on Revision Control”