Date: Thu, 30 May 2019 14:29:47 -0400 From: Ed Maste <emaste@freebsd.org> To: Grzegorz Junka <list1@gjunka.com> Cc: freebsd-git@freebsd.org Subject: Re: Git handling of commit times Message-ID: <CAPyFy2AQ4oKwOLkrZ2AgX1FWS2gmic3AD90CO8oSytM=3ZX4OA@mail.gmail.com> In-Reply-To: <c1ec3909-eeb8-c852-9167-436e9a0d0e72@gjunka.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> <c1ec3909-eeb8-c852-9167-436e9a0d0e72@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 May 2019 at 14:12, Grzegorz Junka <list1@gjunka.com> wrote: > > 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? Presumably, yes, and this is all in order to address dteske's concern about misordering when rendering changes. Note also that (2) is not a requirement per se but instead imposed by (1) (otherwise, someone may make an "in the future" commit which then prevents someone else from making a commit with the "correct" time). > 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? Correct the clock, and do the rebase or merge (but critically, not the actual commits) again. Enable ntpd or clock-refresh-after-resume or etc. on the client to avoid issues next time. > 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. This whole issue is a bit off in the weeds, since it's really a discussion about a way to prevent a hypothetical case that might affect the way commits are ordered/rendered by certain tools. And while I agree this may have a small negative impact on user experience I think it's fairly easy to recover from. We could also look at extending the communication with the server (for 'git fetch') and produce a warning if the local time is appreciably different from the server, with a goal of prodding the user into fixing it earlier. > Besides, how often do you think it will happen that local time suddenly > went backward and the hook would be triggered? IMO it would happen very rarely - so if it does solve a rendering issue (with GitHub, etc.) and almost never triggers it seems like it wouldn't be much of a burden.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2AQ4oKwOLkrZ2AgX1FWS2gmic3AD90CO8oSytM=3ZX4OA>