| @@ -49,10 +49,14 class Repository::Git < Repository | |||||
| 49 |
|
49 | |||
| 50 | # With SCM's that have a sequential commit numbering, redmine is able to be |
|
50 | # With SCM's that have a sequential commit numbering, redmine is able to be | |
| 51 | # clever and only fetch changesets going forward from the most recent one |
|
51 | # clever and only fetch changesets going forward from the most recent one | |
| 52 | # it knows about. However, with git, you never know if people have merged |
|
52 | # it knows about. | |
|
|
53 | # However, with git, you never know if people have merged | |||
| 53 | # commits into the middle of the repository history, so we should parse |
|
54 | # commits into the middle of the repository history, so we should parse | |
| 54 | # the entire log. Since it's way too slow for large repositories, we only |
|
55 | # the entire log. | |
| 55 | # parse 1 week before the last known commit. |
|
56 | # | |
|
|
57 | # Since it's way too slow for large repositories, | |||
|
|
58 | # we only parse 1 week before the last known commit. | |||
|
|
59 | # | |||
| 56 | # The repository can still be fully reloaded by calling #clear_changesets |
|
60 | # The repository can still be fully reloaded by calling #clear_changesets | |
| 57 | # before fetching changesets (eg. for offline resync) |
|
61 | # before fetching changesets (eg. for offline resync) | |
| 58 | def fetch_changesets |
|
62 | def fetch_changesets | |
General Comments 0
You need to be logged in to leave comments.
Login now