From owner-freebsd-git@freebsd.org Wed May 29 18:27:51 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 12D2615A960F for ; Wed, 29 May 2019 18:27:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 D889F80598 for ; Wed, 29 May 2019 18:27:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f47.google.com with SMTP id r185so2718507iod.6 for ; Wed, 29 May 2019 11:27:49 -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=tV88jZYDPiEpePr+t25WN2X6foxVRscaX5yefdZyrXs=; b=Vqtay46fwgU596vZu8XS+l/Wm5MhWE3PpXRvdbBWT0OlGjdAoDsAxqn3tJpqtQHPky rt3hRI+ryzlUbSvYw7KYl5PW82cz1T8ADZ6L4xbW67CDfYpZHq1Q+jdzbp+wSsP8YGQM wKSZfkY4azDzAxkFBK8P1UAMZk+45BviMCpQVsAJCZE0TYEpTqxqXYz8yJGA2Y051QjA OGb8eEmx/18rtCqTbcBRrIDEXjPJHyCNXwze/MdUQOcgctQqspwDC76mKB9gnfMlxgen XGgKUmx76cOoHQM8w+ItkEJ4ecN/5/vGMwdD+4YinTTyNkqhXMWGC0aEACGMGruBWtaV B6dA== X-Gm-Message-State: APjAAAVqJwIwl8OdxNM/xFIz/eqvBpsNOZk5OhTGxnnODZKbP8cLZN6t dblcCdtC0lLAfn3MacU0vh/V5t0+Jd4mtyy4mfTXuw== X-Google-Smtp-Source: APXvYqx/DjTFirFJc1YmYhPeXacaDpvAM6oLBzR+TDEUu057r/u8vOX5gIPJnVngSrMDB4kdqAA7eM3eJjKhJswLhVk= X-Received: by 2002:a5d:8712:: with SMTP id u18mr20498098iom.18.1559154463357; Wed, 29 May 2019 11:27:43 -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: <82938a26-892e-0459-aa23-bdcd9e318b6c@gjunka.com> From: Ed Maste Date: Wed, 29 May 2019 14:27:28 -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: D889F80598 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.55 / 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)[47.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.88)[-0.877,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.66)[ip: (-7.57), ipnet: 209.85.128.0/17(-3.37), asn: 15169(-2.29), 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: Wed, 29 May 2019 18:27:51 -0000 On Wed, 29 May 2019 at 13:58, Grzegorz Junka 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. > 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).