Mercurial and Git both support the ability to attach arbitrary key-value string data to commits. There is an abundance of awesomeness that could be realized if we started storing [machine readable] information inside our commits (not inside the commit messages). Here are some examples:
* Who the reviewer was. (It might be useful to have that more strongly defined so you don't have to parse it out of the commit message.) * Who approved the uplift. (OK, fine, it's a corollary of the above.) * The bug number. (The bug just needs to be somewhere in the commit. Does it really need to be in the message, taking up space?) * The URI of the bug/issue. (Want to automatically link to GitHub issues or some other random issue tracker, sure!) * The URI of the code review. (Like to GitHub pull requests or to other review tools if we ever supplement Splinter.) * GPG signature of commit. (Validate authenticity of patches.) * Which test suites this patch likely affects. (Could be used to reduce automation load by only running those suites on push.) * Which platforms this patch likely affects. (Similar to above.) * Special annotations like "bustage fix," "docs only," "backout," etc. (Could be useful.) * Bugzilla product and component. (Redundant with bug number/URI, but it could save a few lookups.) * DONTBUILD (It doesn't need to be in the commit message.) * CLOSED TREE (Ditto.) * Which revisions were backed out. (Surely there could be a use.) * ... and many more (please entertain the thread) The downside to storing these is that, well, you need to store them. AFAICT neither Mercurial not Git offer a method in the standard CLI to define extra annotations on commits. But, you probably wouldn't want to rely on manual defining anyway since it would be cumbersome. So, you need to deploy a Mercurial extension or Git command to prompt for and record the metadata. So, that means everyone needs to change how they use Mercurial and/or Git (we could enforce usage via server side push hooks). On the surface, that's unfortunate. But, look at the possible benefits of recording this information! The ability to reduce infra load by annotating and running only impacted tests is alone worth seriously looking into this. Plus, once the door is open to collecting one piece of metadata, the only limit to collecting infinite pieces of data is the patience of commiters to enter said metadata (although lots of metadata could presumably be automatically populated). Alternatively, we could continue stuffing more and more metadata inside the commit message. But, this requires more involved parsing (never a fun problem to solve), pollutes our commit messages with spew intended for machines, and requires humans to formulate messages intended for machines that the parser will detect (unless we deploy an extension or hook - at which point we should just store it in the commit object in dedicated fields). Also, once we open the you-need-to-install-version-control-customizations-to-develop door, that provides an opportunity to also put productivity-enhancing extensions such as Bugzilla and review integration into the hands of more developers (they'd get it for free if everything is bundled together). As Charlie Sheen would say, WINNING. Thoughts? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
