clarify which case fails

[ikiwiki.git] / doc / bugs / Git:_changed_behavior_w.r.t._timestamps.mdwn

diff --git a/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn b/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn
index 5d5b9fc23e67542ca21983cee9aead99141cf0b2..164e62075f84ae8370b42494cf31563ea2a0fe12 100644 (file)
--- a/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn
+++ b/doc/bugs/Git:_changed_behavior_w.r.t._timestamps.mdwn
@@ -178,3 +178,37 @@ done instead of the timestamp when the commit was done.  Is this
 intentional?  Otherwise I could supply a patch.
 
 --[[tschwinge]]
+
+> In order to be nice and fast, the git backend runs git log once
+> and records data for all files. Rather than looking at the log for a
+> given file. So amoung other things, it does not follow renames.
+> 
+> AFAICS, git log only shows merges modifying files if it was a conflicted
+> merge. As the file is then actually modified to resolve the merge
+> I think it makes sense to count the merge as the last modification in
+> that case. --[[Joey]] 
+
+>> That'd be reasonable, but `git log` will also show merges that are not
+>> conflicting (as in my case).
+
+>>> Actually when displaying a merge, `git log --stat` only lists files that
+>>> were actually modified in a new way as part of the merge resolution.
+>>> Ie, if the merge resolution only joins together some of the parent
+>>> hunks, the file is not listed as having been modified.
+>>>
+>>> So, no, ikiwiki's use of git log will not show files modified in
+>>> non-conflicting merges.
+>>> --[[Joey]]
+
+>> Yet, I'm not totally disagreeing with your choice.  With this `git
+>> log` invocation, you're not able to tell from its output whether a
+>> conflict was resolved or not.
+
+>> Also, it's a bit like the *should we use the **author timestamp** or
+>> **commit timestamp*** discussion.  Your code will always use the
+>> latest timestamp.
+
+>> I guess I'll get my head wrapped around that, and it's fine, so this is
+>> [[done]].
+
+>> --[[tschwinge]]