Not sure, it validated and looked clean in both Dingus [1] and CMS Preview mode.
[1] http://daringfireball.net/projects/markdown/dingus On Wed, Mar 26, 2014 at 12:50 PM, Mike Drob <mad...@cloudera.com> wrote: > When I tried staging this, the backticks were still present, post markdown > processing. See http://accumulo.staging.apache.org/git.html > > Not sure what you did differently from the other code blocks... > > > On Wed, Mar 26, 2014 at 12:26 PM, Alex Moundalexis > <anonym...@apache.org>wrote: > >> Clone URL (Committers only): >> >> https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://accumulo.apache.org/git.mdtext >> >> Alex Moundalexis >> >> Index: trunk/content/git.mdtext >> =================================================================== >> --- trunk/content/git.mdtext (revision 1581605) >> +++ trunk/content/git.mdtext (working copy) >> @@ -143,6 +143,24 @@ >> >> `git commit -av` >> >> + Please include the ticket number at the beginning of the log message, >> and >> + in the first line, as it's easier to parse quickly. For example: >> + >> + `ACCUMULO-2428 throw exception when rename fails after compaction` >> + >> + Consider following the git log message format described in >> + [Zach Holman's talk]( >> http://zachholman.com/talk/more-git-and-github-secrets/) >> + (specifically slides 78-98, beginning at 15:20 into the video). >> Essentially, >> + leave a short descriptive message in the first line, skip a line, and >> write >> + more detailed stuff there, if you need to. For example: >> + >> + `ACCUMULO-2194 Add delay for randomwalk Security teardown` >> + >> + `If two Security randomwalk tests run back-to-back, the second test >> may see that the >> + table user still exists even though it was removed when the first >> test was torn down. >> + This can happen if the user drop does not propagate through >> Zookeeper quickly enough. >> + This commit adds a delay to the end of the Security test to give ZK >> some time.` >> + >> 6. Assuming others are developing against the version you also are, as >> you >> work, or before you create your patch, rebase your branch against the >> remote >> to lift your changes to the top of your branch. The branch specified >> here should be the same one you used in step 4. >> >> > -- Alex Moundalexis Solutions Architect Cloudera Government Solutions
