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
Show 21 quoted lines
> On Apr 22, 2018, at 2:09 PM, brian m. carlson <sandals@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
Andrew Wolfe <andrew@schemaczar.com>