#ProxyPassreverse /gitblit http://localhost:8080/gitblit\r
\r
# If your httpd frontend is https but you are proxying http Gitblit WAR or GO\r
-#Header edit Location ^http://([^/]+)/gitblit/ https://$1/gitblit/\r
+#Header edit Location ^http://([^⁄]+)/gitblit/ https://$1/gitblit/\r
\r
#ProxyPass /gitblit ajp://localhost:8009/gitblit\r
%ENDCODE% \r
\r
*SINCE 0.9.0*\r
\r
-Repositories may optionally be indexed using the Lucene search engine. Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. Like anything else, this has benefits and drawbacks.\r
+Repositories may optionally be indexed using the Lucene search engine. The Lucene search offers several advantages over commit-traversal search:\r
\r
-You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories can not pre-specify indexed branches; you can only specify indexed branches for a repository with commits. Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.\r
+1. very fast commit and blob searches\r
+2. multi-term searches\r
+3. term-highlighted and syntax-highlighted fragment matches\r
+4. multi-repository searches\r
\r
-**NOTE:** \r
-Repositories that specify indexed branches will redirect to the Lucene search page from the search box in the upper right corner of a repository page. Repositories that do not specify any indexed branches will use the traditional commit search.\r
+### How do I use it?\r
+\r
+Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. \r
+Like anything else, this design has pros and cons.\r
+\r
+#### Pros\r
+1. no wasted cycles on repositories you will never search\r
+2. you specify exactly what branches are indexed; experimental/dead/personal branches can be ignored\r
+\r
+#### Cons\r
+1. you have to opt-in a repository _after_ it is created and has some commits\r
+2. you specify exactly what branches are indexed\r
\r
-The Lucene search offers several advantages over the traditional commit search:\r
+#### Why does Gitblit check every 2 mins for repository/branch changes?\r
\r
-1. multi-term searches\r
-2. term-highlighted and syntax-highlighted fragment matches\r
-3. multi-repository searches\r
+Gitblit has to balance its design as a complete, integrated Git server and its utility as a repository viewer in an existing Git setup.\r
+\r
+Gitblit could build indexes immediately on *edit repository* or on *receiving pushes*, but that design would not work if someone is pushing via ssh://, git://, or file:// (i.e. not pushing to Gitblit http(s)://). For this reason Gitblit has a polling mechanism to check for ref changes every 2 mins. This design works well for all use cases, aside from adding a little lag in updating the index.\r
+\r
+#### Indexing Branches\r
+You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories can not pre-specify indexed branches; you can only specify indexed branches for a repository with commits. Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.\r
+\r
+**NOTE:** \r
+After specifying branches, only the content from those branches can be searched via Gitblit. Gitblit will automatically redirect any queries entered on a repository's search box to the Lucene search page. Repositories that do not specify any indexed branches will use the traditional commit-traversal search.\r
\r
## Client Setup and Configuration\r
### Https with Self-Signed Certificates\r
projects / gitblit.git / commitdiff