Issue #1: The issue was that the HTML view basically showed the blob as all newlines – it displayed as many line numbers as the file had, but all of the lines empty. Not a browser-side display issue, either; the source served up outright didn’t contain the content.

Issue #2: The problem with the current behavior is that the diff displays an author together with changes the author didn’t make, so we ended up with people who got upset that cgit seemed to attribute actions to them that they didn’t perform. It’s a social issue as much as anything; the git show behavior communicates better that it’s just a merge.

Issue #3: What we saw was that it didn’t update the mentioned place in ~20 hours or so, but maybe we had the expiry knob turned the wrong way (though afaik we were using default settings).

Re. issue #1: Unable to reproduce. AFAICS on my cgit install (unfortunately not accessible from outside my company’s firewall), the blob displays correctly. I copy-pasted the text to a file, and diffed it against the ‘plain’ download, and there was no diff (except for a couple of lines with trailing whitespace in the plain version (probably “removed” by the browser in the ‘tree’ view))

Re. issue #2: Reproduced. AFAICS, cgit always shows the diff against the first parent, both for merge commit and regular commits (where the first parent is the only parent). However, ‘git show’ (and also Redmine, Gitorious and gitweb, I assume) uses the “combined” diff format when displaying merge commits (which often shows an empty diff for merges without conflicts). It should be fairly straightforward to add the same behaviour to cgit. I’ll try to look more into it, hopefully next week.

Re. issue #3: AFAICS the caching in cgit maps a request (URL with query parameters) to a cached response. If the underlying repo has changed in the meantime, it seems the cached response is not invalidated. Rather it will return the cached/stale response until it expires (by default after 15 minutes IINM, although this can be configured). I’m not sure whether this should be considered a bug in the caching code, or if it’s seen as a necessary tradeoff when enabling caching. In any case, I suspect that even is you disable caching, cgit will still beat gitweb performance-wise with a comfortable margin.

Johan:
1. It’s not displaying this blob correctly: http://cgit.kde.org/amarok/amarok/tree/README (“plain” works)
2. It’s showing a bogus diff for this merge commit (while git show, Redmine, Gitorious and gitweb show none, as expected): http://cgit.kde.org/konversation/konversation/commit/?id=7d1cb2fae86290da76ee0d0ded602c777f6e0ac8
3. The caching appears to be wonky in practice, e.g. with caching enabled it won’t update the Branch table on the “summary” page to show the actual latest commit.