Date: Wed, 29 May 2019 15:26:13 -0600 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@freebsd.org> Cc: Grzegorz Junka <list1@gjunka.com>, freebsd-git@freebsd.org Subject: Re: Git handling of commit times Message-ID: <CANCZdfpoaqpNpKZrPmkdvZxMty4ZA2xj51Zu_brJrAdydDAakg@mail.gmail.com> In-Reply-To: <CAPyFy2Dm9yWepO6P8jyF%2BNZDA=ZUpg0tYUQ8zRTAKkVWp6cHhw@mail.gmail.com> References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <CAPyFy2Bqg6m8D6rO%2Bg87Wk74iBYOGfq%2B=t6B_VhUM26mUZXO%2BQ@mail.gmail.com> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> <CAPyFy2CkyET7v6hTfhv8ZQ=%2BSYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com> <82938a26-892e-0459-aa23-bdcd9e318b6c@gjunka.com> <CAPyFy2Dm9yWepO6P8jyF%2BNZDA=ZUpg0tYUQ8zRTAKkVWp6cHhw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 29, 2019 at 12:27 PM Ed Maste <emaste@freebsd.org> wrote: > On Wed, 29 May 2019 at 13:58, Grzegorz Junka <list1@gjunka.com> wrote: > > > > You mean undesirable cases? Since it's only metadata for git, these are > > not invalid per se. > > Not invalid from the perspective of the Git DAG, but from the > perspective of causality and time. Yes, the git client will allow me > to create a commit dated next week (as it should). That said it'd be > just fine for the server to refuse to accept such a commit on the > basis that it's not actually valid. > I think this is not a viable position to stake out. The very simple work flow of git branch -b foo hack git commit <time passes> git checkout master git pull git rebase -i master foo <repeat sequence> would setup a situation where commits are in the past. By default, rebase commits don't have their timestamps reset. This means that you can have commits in any sort of weird order, and they can be days, weeks, months even years in the past depending on how long the branch took to develop. Nobody sees this today because people using git svn have the timestamp reset when pushing to svn because there's no notion of setting a time on the commit. Also, resetting the time changes the hash of the commit, iirc. Now, this isn't the 'next week' case, but it shows that trying to be too pedantic about this will lead to issues. > > - commit time is later than the (accurate) server time > > > > That would require a trip over the internet from a hook. Still doable > > but not very user-friendly (as I mentioned earlier). > > Yes, this would have to be done on the server side. But, I don't think > it's unfriendly for the server to deny a commit based on that commit > reportedly happening in the future. > Depends on how far in the future. Time is an illusion. git commit time doubly so :) But this assumes that all the world's clocks are in sync, and they are not. minutes of difference often exist. it's a royal pita to be on the wrong side of the sync when pushing commits upstream to a server you have no control over the time of. > > However, hooks may > > be per branch, so checking time with the server could be done only for > > example when merging/committing to a particular branch (e.g. so that > > someone could commit without restrictions on their branch but when > > merging with upstream branch the local time would be enforced to be > > matched with the server time). > > Yeah, in this discussion I'm assuming that any such checks are > performed only on the canonical repository, which likely holds only > "official" branches. Forks and derived repositories are free to apply > whatever commit hooks they see fit (or not). > This bit is wise. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpoaqpNpKZrPmkdvZxMty4ZA2xj51Zu_brJrAdydDAakg>