From owner-freebsd-git@freebsd.org Wed May 29 17:09:21 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 55FBC15A7A27 for ; Wed, 29 May 2019 17:09:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (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 6EE8F758D9 for ; Wed, 29 May 2019 17:09:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f182.google.com with SMTP id g24so5133847iti.5 for ; Wed, 29 May 2019 10:09:20 -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=HgPbSRi7Ytv1r5arPagxg9FzSTnVWWBhwhaZgtI6EOw=; b=WEEmbmAK5DNnISEnf/Si49VJ2bTGvgN2mQB1wVq6rgDMRQiAwXi+53ORgPnYX91/RQ o7IpZ6Zsw7+i8/eJFTr7IWAIPHg3f/OXNJBHSKfIHiMfYRthk0qh+xtfU7wdPb63bhdd gSSM0pOF8N69QcOfALpqZ0yZtYrfkFv+al26Ttq0La+OTkhGzFawx+K9jKtzeNzJuo/6 lbfJ0KR5STK+uBotd9JG6AYA3gCgO3BTTWQBb8xNMD23YiPyQquCJhG/ZdZaz84Ya77V Er03pKgVlxGTAhMK80fGVqp8udQnEyiOBItSJfuyT7245wB6F/kYLcnqJxUVlt0HhfnG FYrw== X-Gm-Message-State: APjAAAXkBgalrv2ddvnBcZxrwTTjimQ7io/SZDVx5K5672vOI7wZVtyh WxPMnCKJLR/l2/O6GPpvqVP710eO+bbl1K+mxxU= X-Google-Smtp-Source: APXvYqxlPxn6gSehcJSem2tfVrXzzkDNZ1OoF8ibeSEcPuGTWeUFSpBZU6dgljZ7zeJ1TWmvLGvETBadkkGJElOLn8U= X-Received: by 2002:a24:d28a:: with SMTP id z132mr4647820itf.48.1559149753963; Wed, 29 May 2019 10:09:13 -0700 (PDT) MIME-Version: 1.0 References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> In-Reply-To: <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> From: Ed Maste Date: Wed, 29 May 2019 13:08:59 -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: 6EE8F758D9 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.31 / 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)[182.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.82)[-0.822,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.48)[ip: (-6.68), 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 17:09:21 -0000 On Wed, 29 May 2019 at 11:40, Grzegorz Junka wrote: > > Timestamp alone doesn't give much information. What matters is when the > branch in which the commit was added has been merged with other branches > (shown as merge commits in the history). Our history is mostly devoid of merges though, but your broader point is certainly valid - the relationship that's actually important is the parent/child commits, not the order of either date stamp. > Bear in mind that commits are local (by the virtue of git being > distributed scm). You can certainly write a git hook that verifies local > time to be approximately the same as server time and stop the commit if > that's not the case. But that's clunky and patronizing in my opinion\ > (e.g. someone won't be able to commit when on a train and off the grid). I'm not suggesting that we require the commit time to be close to the server time, just that we could disallow two actually invalid cases: - commit time is earlier than parent(s) - commit time is later than the (accurate) server time If you have local commits made while on the train and someone else pushes to the canonical repository before you're back online you're going to have to merge or rebase, and will then have an updated commit time. The solution to this issue triggering is easy - just make sure the client has the correct time. > Git commits are joined by hashes, timestamp is only some metadata. It > makes sens to talk about amount of commits since a particular hash but > not so much about amount of commits since a particular date. Indeed, but that said developers like to think in terms like "commits since a particular date", and we should provide a good experience there if we can do so without restricting realistic workflows.