On 2012-02-17 7:21 AM, Philip Martin wrote:
- mtime only changes. The old branch treated a file with only an mtime
change as unmodified: it did not show up in status or diff and did not
get committed. That was convenient from an implementation point of
view, but hard to justify otherwise. I think mtime only changes
should be treated as modifications.
Based on the use cases I posted in my last email, I think all of them
would either be ambivalent to the decision, or would prefer treating
them as modifications.
Outside of those use cases, there's definitely some situations where
treating them as modifications would annoy people used to the status
quo. Log files and compiler-generated files spring to mind.
So if you add the option to treat mtime-only changes as modifications, I
definitely don't think it should be the default option. It's also
probably safe to leave that option out until some squeeky wheels speak up.
- merge conflicts. The property will often conflict on merge, some
automatic resolution is probably required. I think the old branch
ignored this problem.
I think it needs to be automatically resolved, but I don't think it
matters how it's resolved. Obvious choices would be:
A) now()
B) the latest of the two times
C) delete the property
Merging necessarily modifies the local file, so no matter which
resolution you pick, you'll get a new text-time the next time you commit.
-Rick-
