From owner-freebsd-git@freebsd.org Thu May 30 18:30:09 2019 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7327515A7482 for ; Thu, 30 May 2019 18:30:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 933E8977C9 for ; Thu, 30 May 2019 18:30:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f176.google.com with SMTP id i63so6719302ita.3 for ; Thu, 30 May 2019 11:30:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z4tfqrSVwKJKcBetrbrRH2hVenKvUeyKtB9JbvDwdrA=; b=giaH9kQsZSV1gbcEhHWnLzvik7zoZDPKRR07aMcCPaO7Y9vbp3tMA3T7/X8IZfdiR3 +oEl9UZkgEloRIlWlJH+tb1wilw0WSmhfl249BcwBsxb9H9BMQBgVDDupjeDlAmY6Yk3 FqeNkuLbm0TMn24G9UIdU1kL+EepihXelk5rdeJIKV+aonBfMpTzbAoGQ/7hFCP7sXJk JQxcWO7HzM2i+OlgDwh3HqrK+qq09CsJ72MHJzDrACnHoHm/gETm0cXo8BQy4ptjmD73 5dT+oRoJYyQxuF357qYeGdrQYhgoCt3EU8NPlhrNxm3FOTPuWLOHeEoxdyMLN63gxPIP gdfA== X-Gm-Message-State: APjAAAWLDJV1mImPowHvZuLWiuU/+YbHq98gtpBMSDxaYScN9Zfk76cU L2bdCL839BOA3+01Jki7VOlyFa6/PSg5acFGgkZsjQ== X-Google-Smtp-Source: APXvYqyhHwYCyFaf2yyb2AygG4i7EK7B/zhPeg2UBgG0I/Aq3aOgLHf5ErrF6q9LYp54TpIofSbWHPC6zc5YE+oqFpI= X-Received: by 2002:a24:fec9:: with SMTP id w192mr3860422ith.44.1559241002486; Thu, 30 May 2019 11:30:02 -0700 (PDT) MIME-Version: 1.0 References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> <82938a26-892e-0459-aa23-bdcd9e318b6c@gjunka.com> In-Reply-To: From: Ed Maste Date: Thu, 30 May 2019 14:29:47 -0400 Message-ID: Subject: Re: Git handling of commit times To: Grzegorz Junka Cc: freebsd-git@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 933E8977C9 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.176 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[176.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.85)[-0.846,0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; IP_SCORE(-2.27)[ip: (-5.62), ipnet: 209.85.128.0/17(-3.37), asn: 15169(-2.28), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 18:30:09 -0000 On Thu, 30 May 2019 at 14:12, Grzegorz Junka 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.