* Git enhancement request - checkout (clone) set modified dates to commit date @ 2018-04-22 17:18 Andrew Wolfe 2018-04-22 18:09 ` brian m. carlson 0 siblings, 1 reply; 6+ messages in thread From: Andrew Wolfe @ 2018-04-22 17:18 UTC (permalink / raw) To: git; +Cc: Andrew D Wolfe Jr Hello, there are several timestamps in the lifecycle of a modification to a file in Git: • file write timestamp • git add timestamp • git commit timestamp • git push timestamp • git merge timestamp • git checkout timestamp Right now when I check out/clone a repository, all the files have the checkout timestamp as • ctime - creation time for the file • mtime - modification time for the file • atime - las access time for the file Not only does this force more work for timestamp-based build programs, it also deprives me, as a developer, of a visual 'file blame' that could be very useful in spotting changes without having to do git log over and over. 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. When repository servers have different clocks - which is normal - each clone/merge/push should record the time offset. Each timestamp on each commit should be corrected to the repository's specific time, and that should be a marking on the history. Sincere regards, Andrew Wolfe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git enhancement request - checkout (clone) set modified dates to commit date 2018-04-22 17:18 Git enhancement request - checkout (clone) set modified dates to commit date Andrew Wolfe @ 2018-04-22 18:09 ` brian m. carlson 2018-04-22 19:01 ` Andrew Wolfe 0 siblings, 1 reply; 6+ messages in thread From: brian m. carlson @ 2018-04-22 18:09 UTC (permalink / raw) To: Andrew Wolfe; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1002 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 867 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git enhancement request - checkout (clone) set modified dates to commit date 2018-04-22 18:09 ` brian m. carlson @ 2018-04-22 19:01 ` Andrew Wolfe 2018-04-22 19:59 ` Kevin Daudt 0 siblings, 1 reply; 6+ messages in thread From: Andrew Wolfe @ 2018-04-22 19:01 UTC (permalink / raw) To: brian m. carlson; +Cc: Andrew D Wolfe Jr, git 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 <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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git enhancement request - checkout (clone) set modified dates to commit date 2018-04-22 19:01 ` Andrew Wolfe @ 2018-04-22 19:59 ` Kevin Daudt 2018-04-23 0:23 ` Andrew Wolfe 0 siblings, 1 reply; 6+ messages in thread From: Kevin Daudt @ 2018-04-22 19:59 UTC (permalink / raw) To: Andrew Wolfe; +Cc: brian m. carlson, git On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote: > 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. > Say I build the project while on a certain branch. Then I checkout a different branch and build again. You would expect that the targets of every source file that have changed are rebuilt. When you would restore the timestamp back to the commit timestamp, the timestamp will be older then the target, and make will not rebuild it, leaving you with outdated build targets. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git enhancement request - checkout (clone) set modified dates to commit date 2018-04-22 19:59 ` Kevin Daudt @ 2018-04-23 0:23 ` Andrew Wolfe 2018-04-23 3:32 ` Jacob Keller 0 siblings, 1 reply; 6+ messages in thread From: Andrew Wolfe @ 2018-04-23 0:23 UTC (permalink / raw) To: Kevin Daudt; +Cc: Andrew D Wolfe Jr, brian m. carlson, git Kevin, thanks for your feedback. You have a reasonable point, because usually you don't put the outputs of a build into version control, but the build script checks them for being current. On the other hand, when you change branches, your existing output directories are worthless problems anyway — even if you have all the interdependencies correct. Because of this, I'm inclined to consider this use case as intrinsically hazardous. When I do a checkout, I always want to purge all the intermediate and end targets regardless. When doing a build, it's often useful to put the current commit/branch into the output directories as documentation; I usually do this in my build scripts. This also makes it simple to detect when the branch is changed and clean the outputs. - Andrew > On Apr 22, 2018, at 3:59 PM, Kevin Daudt <me@ikke.info> wrote: > > On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote: >> 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. >> > > Say I build the project while on a certain branch. Then I checkout a > different branch and build again. You would expect that the targets of > every source file that have changed are rebuilt. > > When you would restore the timestamp back to the commit timestamp, the > timestamp will be older then the target, and make will not rebuild it, > leaving you with outdated build targets. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git enhancement request - checkout (clone) set modified dates to commit date 2018-04-23 0:23 ` Andrew Wolfe @ 2018-04-23 3:32 ` Jacob Keller 0 siblings, 0 replies; 6+ messages in thread From: Jacob Keller @ 2018-04-23 3:32 UTC (permalink / raw) To: Andrew Wolfe; +Cc: Kevin Daudt, brian m. carlson, Git mailing list On Sun, Apr 22, 2018 at 5:23 PM, Andrew Wolfe <andrew@schemaczar.com> wrote: > Kevin, thanks for your feedback. > > You have a reasonable point, because usually you don't put the outputs of a build into version control, but the build script checks them for being current. > > On the other hand, when you change branches, your existing output directories are worthless problems anyway — even if you have all the interdependencies correct. Because of this, I'm inclined to consider this use case as intrinsically hazardous. When I do a checkout, I always want to purge all the intermediate and end targets regardless. Not every build has this problem, and certainly I think some of the most common build software would not (Make). It's fairly easy to fix this by using a git hook to update files post checkout (you can look up the timestamp of each file's commit time, or any other time and use touch to do this yourself). Thanks, Jake ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-04-23 3:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-22 17:18 Git enhancement request - checkout (clone) set modified dates to commit date Andrew Wolfe 2018-04-22 18:09 ` brian m. carlson 2018-04-22 19:01 ` Andrew Wolfe 2018-04-22 19:59 ` Kevin Daudt 2018-04-23 0:23 ` Andrew Wolfe 2018-04-23 3:32 ` Jacob Keller
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).