Hi Brian, Not completely sure what you're saying. If the files on master are not changed, the changed files' commit timestamps will be older than the branch commit timestamps.
However, if I check out master after committing to a branch, the modifications will necessarily disappear because they haven't been committed to master. Instead, under my proposal, each will get the timestamp of its prior commit. If you're doing a merge, it will entail a commit and, again, the modified files will be newer. I don't think your use case breaks my proposal. - Andrew Wolfe > On Apr 22, 2018, at 2:09 PM, brian m. carlson <sand...@crustytoothpaste.net> > wrote: > > On Sun, Apr 22, 2018 at 01:18:10PM -0400, Andrew Wolfe wrote: >> I would like to propose that the checkout process set the create and >> modification times of a file to the timestamp at which a file was committed. > > The reason Git doesn't do this is pretty simple: make and various other > tools do rebuilds depending on timestamps. > > If I create a branch off master and make some commits, then switch back > to master, I will want the changed files to have their timestamps > updated to be newer so that a make on master will rebuild dependencies > based on those files. If I set the files to the commit timestamp, those > files would be set to the timestamp of master, which is older than my > new branch, and make wouldn't work properly. > > There are some cases where people want the behavior you requested, such > as for reproducible builds, and in such cases, you can use a > post-checkout hook to set timestamps with touch. > -- > brian m. carlson: Houston, Texas, US > OpenPGP: https://keybase.io/bk2204
