ghazel@xxxxxxxxx wrote: > On Fri, Dec 3, 2010 at 4:51 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> ghazel@xxxxxxxxx wrote: >>> Â Â Â Â Â Â ÂMy deploy process (capistrano) maintains a cached copy of >>> a git repo, which it fetches, resets, and then hardlinks files from >>> when a deploy occurs ( https://github.com/37signals/fast_remote_cache >>> ). The hardlinking step is meant to save the time of copying the file. >>> but hardlinking changes the ctime of the source files. >> >> Interesting. ÂSetting "[core] trustctime = false" in the repository >> configuration could be a good solution (no performance downside I can >> think of). > > This is a very useful suggestion. I do not see a case where ctime > would be valuable to me. Is it really valuable to other people? What > is the trade-off? Some reading for a rainy day :): [1] and surrounding discussion. Short answer: I think the main purpose is catching worktree corruption (e.g., if rsync screws up). [1] http://thread.gmane.org/gmane.comp.version-control.git/89370/focus=89993 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html