Changes between Version 18 and Version 19 of TracGit

Timestamp:

Jun 1, 2015, 9:36:26 PM (9 years ago)

Author:

Ryan J Ollos

Comment:

Put the simplest troubleshooting step first.

TracGit

@@ -136 +136 @@
 == Troubleshooting 
 
-* For Trac < 1.0.2, the `repository_dir` in the configuration section needs to be the `.git` repository directory (i.e. the one containing the file `HEAD` and `config`), not the working tree directory that holds the `.git` folder (#11297). However, a `bare` repository will have these control files in the top-level directory and will not contain a `.git` directory.
-* Wrong permissions may also be the cause of the error `GitError: GIT control files not found, maybe wrong directory?`. Make sure the repository path is accessible via git by the `tracd` process. 
-* If you are noticing a slow down in trac with a repository above 500 commits, try disabling the caching. It seems to bog things down as a repo grows(!)
 * Don't forget to enable the plugin:
  {{{#!ini
@@ -144 +141 @@
 tracopt.versioncontrol.git.* = enabled 
 }}}
+* For Trac < 1.0.2, the `repository_dir` in the configuration section needs to be the `.git` repository directory (i.e. the one containing the file `HEAD` and `config`), not the working tree directory that holds the `.git` folder (#11297). However, a `bare` repository will have these control files in the top-level directory and will not contain a `.git` directory.
+* Wrong permissions may also be the cause of the error `GitError: GIT control files not found, maybe wrong directory?`. Make sure the repository path is accessible via git by the `tracd` process. 
+* If you are noticing a slow down in trac with a repository above 500 commits, try disabling the caching. It seems to bog things down as a repo grows(!)
 * If you don't see the `shortrev` and `commit` branch, you probably have caching enabled (`cached_repository = true`, `persistent_cache = true`). Set those to false.
 * For Trac < 1.0.2, the source browser can throw an error when trying to kill a git log process; it's not clear why it should be an error for the process to have completed.  This problem manifests as a stack trace with terminate_nix at the end (#10958).