Date: Wed, 29 May 2019 10:41:07 -0400 From: Ed Maste <emaste@freebsd.org> To: Devin Teske <dteske@freebsd.org> Cc: freebsd-git@freebsd.org Subject: Re: Git handling of commit times Message-ID: <CAPyFy2Bqg6m8D6rO%2Bg87Wk74iBYOGfq%2B=t6B_VhUM26mUZXO%2BQ@mail.gmail.com> In-Reply-To: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 May 2019 at 23:20, Devin Teske <dteske@freebsd.org> wrote: > > > > > Did anyone ever find an elegant solution to preventing the following edge-case? > > > > 1. Committer uses a VM but keeps it paused most of the time > > > > 2. Committer unpauses VM and makes a commit without first running ntpdate to correct the clock of the paused VM > > > > 3. Committer pushes commit with a timestamp that predates the timestamp for the previous commit on the file in-question > > > > In this case, GitHub renders the commits our of order. If memory serves, "git log" will show them in the proper order, but github web interface shows them in wrong order. It seems to me there are two separate issues here - committing with an incorrect system time, and GitHub's rendering. We should try to avoid the first case (e.g., by hooking into VM infrastructure to have the date set correctly after resume) where we can. I haven't actually checked GitHub's ordering. Git tracks the author and commit timestamps separately. They're often the same (e.g. if I commit a change and push it to a repository) but don't have to be - for example, if I cherry-pick change from someone the author time will be when they originally wrote it, while the commit time will be the time of my cherry-pick. There are other cases where the author time of a pair of changes will be out of order with respect to the commit ordering of those changes -- I may have a change to a file in my tree that I haven't pushed anywhere yet. If you then make a change to that file and I rebase, my change will come after in the commit graph but will have an earlier author time. > > I think there was some talk of a hook to prevent timestamps moving backward with respect to each object being touched in a pushed commit -- is this even possible to prevent? I believe a hook that prevents commit times from going backwards or being ahead of the server time would serve this purpose, but I haven't investigated in any detail. I'm also not sure off hand how GitHub, git, and other tools use author vs commit dates. This is something else that will need more investigation.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2Bqg6m8D6rO%2Bg87Wk74iBYOGfq%2B=t6B_VhUM26mUZXO%2BQ>