1 (brief, sorry, via Phone. More details to follow)
3 I gradually splitting discussion pages into separate comment pages, containing a comment directive.
5 The "date" attribute is being set to the date output by gig for a commit. (I'd hope this was parseable)
7 The presentation of the resulting comments is not sorted by this date, which I would hope/expect, but instead by the ctime or mtime of the file at the other end, as best I can tell.
11 > Yes, comments are displayed via an inline, and usual [[pagespec/sorting]]
12 > (eg, default of when the file was first seen) is used. The comment
13 > date only affects the date displayed.
15 > The only time I've seen this be much problem personally is when moving
16 > a page, which means moving its comments directory, which tends to
17 > jumble the order. (And --gettime does not help, as ikiwiki does not
18 > tell git to follow renames for speed reasons.)
20 > I wonder if it wouldn't be best to just get rid of the extra date
21 > inside the comment, and rely on the file date as is done for other pages.
24 > Altenatively, since comments tend to be named "comment_N_.....",
25 > adding a new [[pagespec/sorting]] method that sorts by filename,
26 > rather than by title, and using it by default for comments might be
27 > better than the current situation. --[[Joey]]
29 >> Since git does not track file time, I tend to prefer to encode date
30 >> stuff inside files where possible. For other pages, I put an explicit
31 >> [[plugins/meta]] date into the source when I create the page. I've
32 >> had to reconstruct ordering after moving to a different git checkout
33 >> after a server move before, it was painful ☺
35 >> In my current situation, I could live with by-filename ordering. By-title
36 >> ordering would also be workable. — [[Jon]]