Arne =?UTF-8?Q?K=C3=B6hn wrote:
> ikiwiki is using
>
> my @sha1s = run_or_non('git', 'rev-list', 'HEAD', '--', $file);
>
>
> in Plugin/git.pm internally, which doesn't follow renames. rev-list
> doesn't support tracking renames, so git log has to be used:
>
> my @sha1s = run_or_non('git', 'log', '--format=tformat:%H', '--follow',
> '--', $file);
>
> This way, the real creation date of the file is used.While git log --follow is probably more expensive, the expense likely doesn't matter since this is just used in --getctime mode. But, more generally, does following renames make sense in determining page creation time? Consider, first, what happens if a page is renamed in an existing wiki, using either git directly, or using the web interface. Ikiwiki sees the old page be removed and the new page be added; the new page's ctime is set to the current time. Currently, running --getctime later will yield the same ctime. Things are consistent. Secondly, look at it from the point of view of someone browsing the web. The ctime data is displayed to them as the post time for a blog post. Suppose that blog post was first edited in staging/, which does not show up on the blog. And was worked on for a month, and finally posted by being moved to blog/. Now, would the user expect to see "Posted today", or "Posted 1 month ago"? I think the former. So the current behavior seems best to me. -- see shy jo
signature.asc
Description: Digital signature
