Date: Thu, 30 May 2019 03:34:48 +0100 From: Grzegorz Junka <list1@gjunka.com> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-git@freebsd.org Subject: Re: Git handling of commit times Message-ID: <ddd946b2-315d-fd44-f82b-2cf894a86bd7@gjunka.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 29/05/2019 19:27, Ed Maste 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. > >>> - 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. That's not what I was referring to. The time when the commit is made is not related to when it's pushed to the remote. I am saying that for this to work the hook on your laptop would need to check the time on the server when the commit is being made locally (e.g. on a train). The commit could be made, say, with tomorrow's date, but pushed to the remote next week. This would be invalid according to your definition (commit made with future date) but still wouldn't be caught (because it's pushed after that future date). Equally, the commit could be made with yesterday's date and if HEAD is a week ago this again wouldn't be caught. From what I understand you want to catch a situation when developer's VM was sleeping and then used to commit changes. In that case the local date will be behind the server's time, not ahead. In any case, if you want to ensure that the timestamp in the commit when it's made locally (on your laptop) makes sense in the context of the server's time, then there is no other way than to check server time when the commit is being made, not when it's beings pushed. Or am I misunderstanding the requirements? > >> 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). Same story as above, I was referring to commits being made locally (on your laptop). Checking anything on the server is too late. Imagine that by accident you committed locally changes with yesterday's date (VM was sleeping) and now server rejects your push. In order to fix this you need to either: 1. Adjust your local time, set environment variables to the time you want to change, then rebase affected commits on top of the last commit that the server wouldn't reject (how to find it is another story). If any of those rebased commits have already been pushed then you suddenly have conflicts that you need to resolve by pulling remote changes, merging and pushing again. 2. Revert X commits up to the commit that the server wouldn't reject. Changed files should be in git staging now. Then you need to update the time and commit the files again. If you made 10 commits with proper commit messages then all this history is lost. After reverting you have all the changes in all the commits in git staging and now you can only commit the files once. Situation becomes more complicated if there was a merge within those commits that you reverted because the staging will contain all changes from all reverted commits. If you had any merge conflicts you will no longer have the history how these conflicts have been resolved, which will impact any future debugging of problems possibly caused by those commits. Either situation is super user unfriendly. If you want to prevent incorrect timestamp then it must be done when the commit is being made locally, not on the server when the commit is being pushed from laptop to the remote repo. Of course you can do both but in my opinion just doing it on the server isn't enough.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ddd946b2-315d-fd44-f82b-2cf894a86bd7>