Date: Thu, 30 May 2019 17:55:44 +0000 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: <c1ec3909-eeb8-c852-9167-436e9a0d0e72@gjunka.com> In-Reply-To: <CAPyFy2Dc%2B4wdDJgJNxYh8F9R9CgijGO-kQ7gtX=awev_D3=bHg@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> <ddd946b2-315d-fd44-f82b-2cf894a86bd7@gjunka.com> <CAPyFy2Dc%2B4wdDJgJNxYh8F9R9CgijGO-kQ7gtX=awev_D3=bHg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30/05/2019 13:34, Ed Maste wrote: > On Wed, 29 May 2019 at 22:34, Grzegorz Junka <list1@gjunka.com> wrote: >> 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). > Yes, the commit time is not related to when it's pushed. But you still > don't need any external access at the time of commit; perhaps I've > been unclear about requirements. The goal here is to ensure that > timestamp ordering matches commit DAG ordering, not that the > timestamps are "correct" for some definition thereof. > > Let me try to clarify the two example cases: > >> The commit could be made, say, with tomorrow's date, but pushed to the >> remote next week. > That case is fine - if you have a post-dated commit that's not yet > part of the canonical tree there's no issue; it's not possible for > someone else to create another commit as a child of yours. The > discussion here is about the view of commit dates in the canonical > repository and a potential commit hook to enforce rules on those; it > does not matter at all what's in a private repo. I see. To reiterate, the aim is: 1. for each commit's timestamp to be later than timestamps of all its parents 2. for the server to only accept commits with timestamps earlier than its local time Is that correct? Imagine that I've been implementing new features and made 100 commits in my branch. I haven't noticed that my time may be incorrect (in the future). I pull remote branch and update my branch with latest changes: git fetch git pull remote_branch No complains so far. The merge commit may be in the future, say a week later than remote_branch/HEAD, but it's still later than their parent, so it's OK. Now I want to push. But a hook on the server complains that I can't because my HEAD is later than their local time. Now what? I agree that you can create a hook to ensure a timestamp in every commit is later than the timestamp in its parent commit(s). I am only arguing that it may negatively impact user experience if another hook doesn't ensure that local time matches remote time at the time local commit is being made. And that's difficult and another burden because it would require internet connection. Besides, how often do you think it will happen that local time suddenly went backward and the hook would be triggered? >> Equally, the commit could be made >> with yesterday's date and if HEAD is a week ago this again wouldn't be >> caught. > That's fine too - as long as the commit is after its parents it's fine. The canonical way of working with commits in git is by their hashes, not timestamps. If you, say, need to know amount of commits since a particular date, you first find a specific commit then use its hash in any git commands. As you know the history in git is made of chains of commits. When branches are merged, their histories are joined in a merge commit, but it doesn't mean that the history becomes linear. Github and git log will show the history in a linear fashion without branches. But if you "git log --graph" you still see separate histories per branch as they were before they have been merged. If some today's commit was made with tomorrow's date it will be shown on that list after other commits in other branches committed today. However, even if a commit has a timestamp that is later than the merge commit, it will still be shown before that merge commit. Git will respect the order of hashes in the first place, then the order of timestamps. So, without any hooks commits would still be shown in the correct order, only date-related git query may not always return absolutely correct data. Is it worth the effort? Just treat timestamps as indicative and all problems are gone. Alternatively a hook can only warn user when the local clock doesn't seem to be correct without treating it as an error. If a developer can correct the situation, they should. If not, well, life isn't perfect. GrzegorzJ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c1ec3909-eeb8-c852-9167-436e9a0d0e72>