From owner-freebsd-git@freebsd.org Tue May 28 13:43:00 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 4487815981DF for ; Tue, 28 May 2019 13:43:00 +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 5F84E816BD for ; Tue, 28 May 2019 13:42:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f176.google.com with SMTP id m140so3950357itg.2 for ; Tue, 28 May 2019 06:42:59 -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:from:date:message-id:subject:to; bh=2U2VprK+xJ2wl2sWd6xnQKaeeJWKQT/VbOVNw2VNEho=; b=BsaiGLIPigybUZnuXzmP17m4y2MN0qmOez72k/QzGe8E+bgastVmzPXvhmHy7Mm1lp XV1BWbIk2KHAZ3SCDXWPD/r+3YYgFFUfEr43lgD73Nf60uHGJcZ4gdlrjUL+C026AX25 lViHmplIbbN1GNHeZyxsJjJCTp8zkLTSZfRr9fx4MIHxduvzjX9s1zfemfOal8ZAPGVg XpwuGLv/xdxFsrYXCQXDou5t2KiwWNS8NS8+XFhswRTKt/uvb2uwZlFbEuB5MX/L7r8+ uBfC0pawGm1doHPMblzWvmUJyNDpIwS+IJ7Yk4YpTuKe+vHXuBIWVI82yLr5t5/2Nscp nf6w== X-Gm-Message-State: APjAAAUriG4EH9jg+WgoHs27kpGr6eE6T+p5d0pb7DRgYNHP4FfGgp7J 6wFFzfSOoLtA1Sk/W2RIxy5/cegj/9ICb/+Zl8Ky+qDD X-Google-Smtp-Source: APXvYqyu1mUasuiDF41ErtwpPnZeHHXXFE+6hM5hWLi9ll6Uwr3LfKRQk+xW9F9t6Ol2NqwpO5m+10+Sa0FHMW3roso= X-Received: by 2002:a02:6a06:: with SMTP id l6mr12225987jac.129.1559050977339; Tue, 28 May 2019 06:42:57 -0700 (PDT) MIME-Version: 1.0 From: Ed Maste Date: Tue, 28 May 2019 03:13:41 -0400 Message-ID: Subject: Speeding up slower Git operations To: freebsd-git@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5F84E816BD 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.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; RCVD_IN_DNSWL_NONE(0.00)[176.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; DMARC_NA(0.00)[freebsd.org]; 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.30)[ip: (-5.76), ipnet: 209.85.128.0/17(-3.39), asn: 15169(-2.29), country: US(-0.06)]; TO_DOM_EQ_FROM_DOM(0.00)[] 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: Tue, 28 May 2019 13:43:00 -0000 Microsoft has been putting a lot of work into improving git performance and scalability with large repositories. A recent development is the addition of the commit-graph feature[1], which caches information about the commit graph and speeds up operations like determining if a commit is on a specified branch, or obtaining the commit count. As an example of the performance gain, the feature's developer reports that a "git branch --contains" on the Linux kernel went from 76.20s to 0.04s. In my FreeBSD tree "git rev-list HEAD --count" went from an average of 2.77s wall clock to 0.39s. This operation (rev-list --count) is interesting as it can serve as a replacement for monotonically increasing version numbers, and with it executing in under half a second it seems like it'd be reasonable to add it to newvers.sh (to bake into uname). To enable the feature, enable the commitGraph option: % git config core.commitGraph true Then populate the commit graph: % git commit-graph write --reachable If you try it please reply and let us know how it worked for you. [1] https://devblogs.microsoft.com/devops/supercharging-the-git-commit-graph/ From owner-freebsd-git@freebsd.org Tue May 28 17:57:35 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 11DDA15A706C for ; Tue, 28 May 2019 17:57:35 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 CB2128AC69 for ; Tue, 28 May 2019 17:57:33 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: by mail-lj1-x244.google.com with SMTP id q16so1478704ljj.8 for ; Tue, 28 May 2019 10:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bakulin-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hzkSLx9m9o4BNNxpq6HfGOqUW5R8ZYTyfdzEXddfZl8=; b=jtutWhLe2rX0N8j/VJ4FZRYbrNmpRl651r8+eAnNQkywFZONxxek9/d+Uj0xQkUgBC EJDfWNgdesO3NobSBUyufjqqygZIhlgSl9pCJfGRiM+1v8pv7RpAcg3wvajvaRkZuvW3 MLUciUc5PKf3D82u6uJEdxteWPiBVEINGCqMDM6S6PMz2ISTtMrpscF0200HDK9E3ElA 6IsokfXscjprFdSwWq6ARIWUtDEUkNT2vvN6FrqDOMj2d1tGK/Rx4yP4nyfBNXGrGAw0 UB0r44CzvhQ0GsC/icFfnCmhleJxdq+CrqZOz/xhg7wYPTzFAOBIRbgFVU0qloXianh8 KElA== 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=hzkSLx9m9o4BNNxpq6HfGOqUW5R8ZYTyfdzEXddfZl8=; b=gCMPwLxMunu5tM57SWhacOdvQbxY87qZzgElegPHFHdBd3hGxXOihZvRXwfcczwbyE iAHQ0hHoTMz2h3UJfczGM0OV06WUC5cDulxxkE2BcWDLMgBP/sXXTD1S032KGM3JGnC/ UKK2pp69BOt2pdlsjcDj/SClQ9EZr2NjY8QamPlbtFP9+QGpTYsuIEDIdBN5rVwuPris 4XIaZfZLE1oAgHOow4XfS8PzXCwwNS6T3qkpUB3+wdkFkGkR9HlXC9Yl2NsqQNQ6+5Wm 8eq+35qx9Kk0scUpvYnVvhrZSQu1DLaf6J96AYKb4e0To7lovGTSbwG5TnSDwhYsiMX7 vKkw== X-Gm-Message-State: APjAAAWgpiKgmyQ88sOzXNhspB3aKIxzcRTYdA5Yo6BE9IfncIMcV9q9 qPXNO5eOk+wKPyZLhFPvQDeNQw6FxtCmxH96vz2EVA== X-Google-Smtp-Source: APXvYqx2g9mnjmEcxsZheJXdiQWDJnctG2ElzfaZVI6pltR536FUvUXMXaQNUvLI6W+hGgMB0TRveZyaxUOlXCXkjRg= X-Received: by 2002:a2e:3101:: with SMTP id x1mr23484527ljx.148.1559066252099; Tue, 28 May 2019 10:57:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ilya Bakulin Date: Tue, 28 May 2019 19:57:21 +0200 Message-ID: Subject: Re: Speeding up slower Git operations To: Ed Maste Cc: freebsd-git@freebsd.org X-Rspamd-Queue-Id: CB2128AC69 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bakulin-de.20150623.gappssmtp.com header.s=20150623 header.b=jtutWhLe X-Spamd-Result: default: False [-0.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.955,0]; R_DKIM_ALLOW(-0.20)[bakulin-de.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.67)[0.673,0]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[bakulin.de]; URI_COUNT_ODD(1.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bakulin-de.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.31)[ip: (3.01), ipnet: 2a00:1450::/32(-2.18), asn: 15169(-2.29), country: US(-0.06)] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 28 May 2019 17:57:35 -0000 You are counting commits behind HEAD which is a mere pointer to the current branch head. So if you are working on some "topic" branch then the number becomes effectively useless since it will count a number of commits behind that topic branch HEAD. So this number alone is not sufficient unless you also append "-dirty" or something else to denote the "canonical" build done from a clean git checkout of the official FreeBSD repository. Which is a good idea anyway, I guess. So that when somebody reports a bug on some mailing list and includes a kernel version number (or freebsd-version output) it's immediately obvious that they are using a non-official kernel. On Tue, May 28, 2019 at 3:43 PM Ed Maste wrote: > Microsoft has been putting a lot of work into improving git > performance and scalability with large repositories. A recent > development is the addition of the commit-graph feature[1], which > caches information about the commit graph and speeds up operations > like determining if a commit is on a specified branch, or obtaining > the commit count. > > As an example of the performance gain, the feature's developer reports > that a "git branch --contains" on the Linux kernel went from 76.20s to > 0.04s. In my FreeBSD tree "git rev-list HEAD --count" went from an > average of 2.77s wall clock to 0.39s. This operation (rev-list > --count) is interesting as it can serve as a replacement for > monotonically increasing version numbers, and with it executing in > under half a second it seems like it'd be reasonable to add it to > newvers.sh (to bake into uname). > > To enable the feature, enable the commitGraph option: > % git config core.commitGraph true > Then populate the commit graph: > % git commit-graph write --reachable > > If you try it please reply and let us know how it worked for you. > > [1] > https://devblogs.microsoft.com/devops/supercharging-the-git-commit-graph/ > _______________________________________________ > freebsd-git@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-git > To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org" > From owner-freebsd-git@freebsd.org Tue May 28 18:55: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 A1B1715A8A3D for ; Tue, 28 May 2019 18:55:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (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 CD7C88CD18 for ; Tue, 28 May 2019 18:55:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f67.google.com with SMTP id e3so5134425ioc.12 for ; Tue, 28 May 2019 11:55:50 -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:content-transfer-encoding; bh=gNJF6T4H8mgVd7oXyrqUpAbEamyCba02vMf+TtdqRzI=; b=RbXHedWhm9yNrQW8jgB+uZ0qSn7T1Lx+Sx/q1ThmvaUfN/NtHsO6KmyHpUvCWqL9yh tkifEVEnERDeEUFAChJTD782VVIk+Ht/oDev3dlBclPk5psX+Ry1Ltw8Y8K8cLzAXN1K gEsdXQoZdDYa1FaxfV8Xlqts+2SWz4oYPZyViJsYfbESD4eoI7aEqAP7JiyfxCbTfpCV zGxDyBPP0ELBcGsEkLqpzthS8Isirqie3yed2VqBZBr3VmMhKKZBJ/2Awzcr9MiSlZ6y KPoiunrvhJzIWBNRuHbYraqqIzjjLRHzDaRuu5vtaaV1JK/vtu91M50HjTjOeLRWpcW5 LPpQ== X-Gm-Message-State: APjAAAVpt86dBqLXf/Rq8neTuKlxKGjtKUt5iBVLQjrHjUxyGAgoRRPL x/n6KJosKXxlsvHK85oSdNhbDWLQMdRToNzYxpg= X-Google-Smtp-Source: APXvYqx3XHo8qVscgeUZBcjgQ6lFSSTY6C0fMLfGAcnhVfAqrfWkym6kODs0hBN4zGRx0CLU3NJPUa5XuJcjzqWBt9A= X-Received: by 2002:a6b:b497:: with SMTP id d145mr5828295iof.17.1559069264986; Tue, 28 May 2019 11:47:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 28 May 2019 08:18:28 -0400 Message-ID: Subject: Re: Speeding up slower Git operations To: Ilya Bakulin Cc: freebsd-git@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CD7C88CD18 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.67 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.92 / 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)[67.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.76)[-0.760,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(-1.15)[ipnet: 209.85.128.0/17(-3.38), 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: Tue, 28 May 2019 18:55:51 -0000 On Tue, 28 May 2019 at 13:57, Ilya Bakulin wrote: > > You are counting commits behind HEAD which is a mere pointer to the curre= nt branch head. So if you are working on some "topic" branch then the numbe= r becomes effectively useless since it will count a number of commits behin= d that topic branch HEAD. So this number alone is not sufficient unless you= also append "-dirty" or something else to denote the "canonical" build don= e from a clean git checkout of the official FreeBSD repository. Which is a = good idea anyway, I guess. Correct. For builds of an unmodified upstream version the (branch, rev-list --count) will be unique and consistent. Today for builds from git we include in uname the corresponding SVN version, the git hash, and the branch - e.g. a test machine here reports "r333291+95e9f145d658(HEAD-TESTING)". I'm not sure what the best way to report it would be, but in the absence of svn we could indicate something like "95e9f145d658(HEAD-TESTING) c251421". > So that when somebody reports a bug on some mailing list and includes a k= ernel version number (or freebsd-version output) it's immediately obvious t= hat they are using a non-official kernel. We do that today as well, appending -dirty for builds from a modified git tree and M from a modified Subversion tree. From owner-freebsd-git@freebsd.org Wed May 29 03:20:17 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 DA5CA15B48AD for ; Wed, 29 May 2019 03:20:17 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BC1A76C52; Wed, 29 May 2019 03:20:17 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [76.77.180.168] (port=60000 helo=[192.168.86.51]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1hVohB-000386-7p; Tue, 28 May 2019 19:52:05 -0700 From: Devin Teske Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 28 May 2019 20:20:05 -0700 Subject: Git handling of commit times Message-Id: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> Cc: dteske@FreeBSD.org To: freebsd-git@freebsd.org X-Mailer: iPhone Mail (15D60) Sender: devin@shxd.cx X-Rspamd-Queue-Id: 0BC1A76C52 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.59 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.82)[0.818,0]; IP_SCORE(0.13)[ip: (0.38), ipnet: 64.201.240.0/20(0.19), asn: 36734(0.15), country: US(-0.06)]; NEURAL_SPAM_SHORT(0.96)[0.963,0]; MX_GOOD(-0.01)[mail.shxd.cx]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.98)[0.985,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[dteske@freebsd.org,devin@shxd.cx]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36734, ipnet:64.201.240.0/20, country:US]; FROM_NEQ_ENVFROM(0.00)[dteske@freebsd.org,devin@shxd.cx]; MID_RHS_MATCH_FROM(0.00)[]; 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 03:20:18 -0000 >=20 > Did anyone ever find an elegant solution to preventing the following edge-= case? >=20 > 1. Committer uses a VM but keeps it paused most of the time >=20 > 2. Committer unpauses VM and makes a commit without first running ntpdate t= o correct the clock of the paused VM >=20 > 3. Committer pushes commit with a timestamp that predates the timestamp fo= r the previous commit on the file in-question >=20 > In this case, GitHub renders the commits our of order. If memory serves, "= git log" will show them in the proper order, but github web interface shows t= hem in wrong order. >=20 > I think there was some talk of a hook to prevent timestamps moving backwar= d with respect to each object being touched in a pushed commit -- is this ev= en possible to prevent? >=20 > Is this no longer an issue? Just looking for clarification on a genuine co= ncern. > --=20 > Devin Forwarding by request to ML =E2=80=94=20 Devin= From owner-freebsd-git@freebsd.org Wed May 29 10:13:54 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 8ABD715BDF0A for ; Wed, 29 May 2019 10:13:54 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.xs4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD61F8C01D for ; Wed, 29 May 2019 10:13:52 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from beastie.bionicmutton.org ([62.251.92.29]) by smtp-cloud7.xs4all.net with ESMTP id VvZch5jTs3qlsVvZdhssPh; Wed, 29 May 2019 12:12:45 +0200 From: Adriaan de Groot To: freebsd-git@freebsd.org Subject: Introduction Date: Wed, 29 May 2019 12:12:38 +0200 Message-ID: <1946748.RhTPgMbj8J@beastie.bionicmutton.org> Organization: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3082735.gzUHUCRiql"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4wfDdgiWrItPruWUbq5qC0YY73sU+wucv9oIBE7ES3LSS/KWCGiEyGHwOUgaDKF8NKnCblGzQeXw+Q/PCWJoC4PbFLc5j7SsyuvoVY0aXHifZmC4Gyo3oL XR7dW6EYqHUHGxBRVpK89h7f0Rs0stPwi3ysbPfKMvdOtpHmUEZptgfWrf4EoVXJ6rQoCwo8bzD+6Q== X-Rspamd-Queue-Id: BD61F8C01D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] 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 10:13:54 -0000 --nextPart3082735.gzUHUCRiql Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Hi all, Presumably Ed will provide a kick-off message soon-ish for the git WG. Reading developers@ has been rather disheartening, mostly because *all* the talking points there are the same as the talking points that KDE went through whenever we switched from SVN (at the time, pretty much the largest SVN repo in the world) to git. Anyway: hi! I'm [ade] on IRC, adridg@ on mail, and Adriaan in real life. I wear KDE and FreeBSD hats, and have a fair amount of experience in juggling svn (FreeBSD), hg (when I did Solaris packaging) and git (KDE) repositories. I used darcs for a month, and CVS of course back in the '90s. If I may make a position statement to start off with (before Ed's kick-off): We need to know what the question is, and then we can untangle all the answers we already have. This sounds a lot like the Hitchhiker's Guide, really. Watching the BSDCan video it looks like core@ is asking the WG "to make the move to git happen". That's rather vague as a mandate and as a question: git for what? Which software or data artifacts are to be moved into git? Does that cover src, ports, docs in their current form? Is some form of repo-reorganization desired? Splitting repo's? Knowing the exact question helps steer discussions around workflow, tooling, and the documentation of workflow and tooling. ports/ *isn't* src/, and works quite differently. Tooling revolves around GitHub, GitLab, git command-line, etc. There's plenty to sort out there both philosophically and practically. All of this against the background of what's *fait accompli*. await(Ed) [ade] --nextPart3082735.gzUHUCRiql Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABEIAB0WIQTVFBoRsP760fy+Jisy7lRaPghTTwUCXO5bFgAKCRAy7lRaPghT T7mQAP9/+TbMBd1dQZTAghrbH/AZjQPTTtkNaI0woSLgyiHFxQD/a99jLQDG2ppq V8l1blKdeLftDukLK0OBEG/Q35s+Hoc= =JIZA -----END PGP SIGNATURE----- --nextPart3082735.gzUHUCRiql-- From owner-freebsd-git@freebsd.org Wed May 29 11:51: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 9CB4115C0585 for ; Wed, 29 May 2019 11:51:51 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8736B8F76D for ; Wed, 29 May 2019 11:51:50 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id x4TBphb4071770 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 29 May 2019 11:51:43 GMT (envelope-from list1@gjunka.com) Subject: Re: Introduction To: freebsd-git@freebsd.org References: <1946748.RhTPgMbj8J@beastie.bionicmutton.org> From: Grzegorz Junka Message-ID: <6ca432ef-d599-3f5b-0e9a-cb14f5f0fbdf@gjunka.com> Date: Wed, 29 May 2019 11:51:43 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1946748.RhTPgMbj8J@beastie.bionicmutton.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-Rspamd-Queue-Id: 8736B8F76D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-6.83 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[gjunka.com]; MX_GOOD(-0.01)[gjunka.com]; NEURAL_HAM_SHORT(-0.88)[-0.877,0]; IP_SCORE(-3.64)[ip: (-9.53), ipnet: 88.98.192.0/18(-4.77), asn: 56478(-3.81), country: GB(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; 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 11:51:51 -0000 On 29/05/2019 10:12, Adriaan de Groot wrote: > Hi all, > > Presumably Ed will provide a kick-off message soon-ish for the git WG. > > Reading developers@ has been rather disheartening, mostly because *all* the > talking points there are the same as the talking points that KDE went through > whenever we switched from SVN (at the time, pretty much the largest SVN repo > in the world) to git. > > Anyway: hi! > > I'm [ade] on IRC, adridg@ on mail, and Adriaan in real life. I wear KDE and > FreeBSD hats, and have a fair amount of experience in juggling svn (FreeBSD), > hg (when I did Solaris packaging) and git (KDE) repositories. I used darcs for > a month, and CVS of course back in the '90s. > > If I may make a position statement to start off with (before Ed's kick-off): > > We need to know what the question is, and then we can untangle all the answers > we already have. > > This sounds a lot like the Hitchhiker's Guide, really. Watching the BSDCan > video it looks like core@ is asking the WG "to make the move to git happen". > That's rather vague as a mandate and as a question: git for what? Which > software or data artifacts are to be moved into git? Does that cover src, > ports, docs in their current form? Is some form of repo-reorganization > desired? Splitting repo's? > > Knowing the exact question helps steer discussions around workflow, tooling, > and the documentation of workflow and tooling. ports/ *isn't* src/, and works > quite differently. Tooling revolves around GitHub, GitLab, git command-line, > etc. There's plenty to sort out there both philosophically and practically. > > All of this against the background of what's *fait accompli*. > > await(Ed) > > [ade] Hi Adriaan, What's WG? What BSDCan video you are talking about, is it possible to include any links? What's core@ and developers@? Can't see any such lists. I've briefly checked the list archives in the last few months and haven't noticed any thread related to this "Introduction". What's going on? If I may, if core@ was asking anything of anyone on this list they would likely post a question here, not do it through a BSDCan video? GrzegorzJ From owner-freebsd-git@freebsd.org Wed May 29 14:41:27 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 002E015C4CA2 for ; Wed, 29 May 2019 14:41:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) (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 131A36F719; Wed, 29 May 2019 14:41:25 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f180.google.com with SMTP id m3so4263879itl.1; Wed, 29 May 2019 07:41:25 -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=3T4hz4NWggxvpSY7dvDhVYYRMrOI9eZmSsbO+5lL1fE=; b=JVJGC6oI9aX4vTNC5aznTAyThWIP8ZE/b4aNBG9duklrAoMrCKnmrVVDeXRyRELyXT u71ZY0QUwC6XFB7E9kBdqCPapMIymp/Ya7O0aMaYmwpkTuvp1yJdoD5GnYfjwSS1yXZt GPKj1S1qnmUl2Y7dJvx9YP/iMvZ/rjMyOQXqQtI6/eLKxrI5DHtuTfE2UW8B0d6+LiqA blhDkmACTArnQ0LPQ9zgZZ86eogbtz7jg63h/AqCbpMvruFZyVi+lEj3XknELfzvFdlf EBk8GTQx4Wyk8N7u51Hr4O7pNucLqNG0AE4h5zt/Hbe9U5frwSfqm2bxwnjmzaR9Kk+0 gerA== X-Gm-Message-State: APjAAAVeOvuVtK/izPPo6icdAaz6Msb4R6Cp6skQrcjzOTIt4ySBhXUH GsBB416CtOksxYlabD4Ewb5AMJTEt7IpRtevzjiuZQ== X-Google-Smtp-Source: APXvYqy9gWe+Nz2UE4u5Le+UzgS5rH+BxqFMdrUOUQ48+Hz4RSElClnRPzz7wWRxsFzIC/WF8acshaft1zWYoetbJfE= X-Received: by 2002:a24:ac52:: with SMTP id m18mr6990538iti.146.1559140883418; Wed, 29 May 2019 07:41:23 -0700 (PDT) MIME-Version: 1.0 References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> In-Reply-To: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> From: Ed Maste Date: Wed, 29 May 2019 10:41:07 -0400 Message-ID: Subject: Re: Git handling of commit times To: Devin Teske Cc: freebsd-git@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 131A36F719 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.180 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-5.48 / 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]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.53)[ip: (-6.94), ipnet: 209.85.128.0/17(-3.38), asn: 15169(-2.29), country: US(-0.06)]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[180.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.94)[-0.936,0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[180.166.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; 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]; 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 14:41:27 -0000 On Tue, 28 May 2019 at 23:20, Devin Teske wrote: > > > > > Did anyone ever find an elegant solution to preventing the following edge-case? > > > > 1. Committer uses a VM but keeps it paused most of the time > > > > 2. Committer unpauses VM and makes a commit without first running ntpdate to correct the clock of the paused VM > > > > 3. Committer pushes commit with a timestamp that predates the timestamp for the previous commit on the file in-question > > > > In this case, GitHub renders the commits our of order. If memory serves, "git log" will show them in the proper order, but github web interface shows them in wrong order. It seems to me there are two separate issues here - committing with an incorrect system time, and GitHub's rendering. We should try to avoid the first case (e.g., by hooking into VM infrastructure to have the date set correctly after resume) where we can. I haven't actually checked GitHub's ordering. Git tracks the author and commit timestamps separately. They're often the same (e.g. if I commit a change and push it to a repository) but don't have to be - for example, if I cherry-pick change from someone the author time will be when they originally wrote it, while the commit time will be the time of my cherry-pick. There are other cases where the author time of a pair of changes will be out of order with respect to the commit ordering of those changes -- I may have a change to a file in my tree that I haven't pushed anywhere yet. If you then make a change to that file and I rebase, my change will come after in the commit graph but will have an earlier author time. > > I think there was some talk of a hook to prevent timestamps moving backward with respect to each object being touched in a pushed commit -- is this even possible to prevent? I believe a hook that prevents commit times from going backwards or being ahead of the server time would serve this purpose, but I haven't investigated in any detail. I'm also not sure off hand how GitHub, git, and other tools use author vs commit dates. This is something else that will need more investigation. From owner-freebsd-git@freebsd.org Wed May 29 15:40: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 BB9CB15A5303 for ; Wed, 29 May 2019 15:40:21 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BE9B671A25 for ; Wed, 29 May 2019 15:40:20 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id x4TFeIJp075138 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 29 May 2019 15:40:18 GMT (envelope-from list1@gjunka.com) Subject: Re: Git handling of commit times To: freebsd-git@freebsd.org References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> From: Grzegorz Junka Message-ID: <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> Date: Wed, 29 May 2019 15:40:18 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-Rspamd-Queue-Id: BE9B671A25 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-6.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[gjunka.com]; MX_GOOD(-0.01)[cached: gjunka.com]; NEURAL_HAM_SHORT(-0.84)[-0.839,0]; IP_SCORE(-3.63)[ip: (-9.50), ipnet: 88.98.192.0/18(-4.75), asn: 56478(-3.80), country: GB(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; 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 15:40:22 -0000 On 29/05/2019 14:41, Ed Maste wrote: > On Tue, 28 May 2019 at 23:20, Devin Teske wrote: >>> Did anyone ever find an elegant solution to preventing the following edge-case? >>> >>> 1. Committer uses a VM but keeps it paused most of the time >>> >>> 2. Committer unpauses VM and makes a commit without first running ntpdate to correct the clock of the paused VM >>> >>> 3. Committer pushes commit with a timestamp that predates the timestamp for the previous commit on the file in-question >>> >>> In this case, GitHub renders the commits our of order. If memory serves, "git log" will show them in the proper order, but github web interface shows them in wrong order. GitHub is the worst way of looking at commit history. Any other way is better than their clunky interface. The issue is that the history isn't linear no matter what you see in the interface. You either need to use Insights/Network or "git log --graph" to make sense of the order of commits. 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). > It seems to me there are two separate issues here - committing with an > incorrect system time, and GitHub's rendering. We should try to avoid > the first case (e.g., by hooking into VM infrastructure to have the > date set correctly after resume) where we can. I haven't actually > checked GitHub's ordering. > > Git tracks the author and commit timestamps separately. They're often > the same (e.g. if I commit a change and push it to a repository) but > don't have to be - for example, if I cherry-pick change from someone > the author time will be when they originally wrote it, while the > commit time will be the time of my cherry-pick. > > There are other cases where the author time of a pair of changes will > be out of order with respect to the commit ordering of those changes > -- I may have a change to a file in my tree that I haven't pushed > anywhere yet. If you then make a change to that file and I rebase, my > change will come after in the commit graph but will have an earlier > author time. > >>> I think there was some talk of a hook to prevent timestamps moving backward with respect to each object being touched in a pushed commit -- is this even possible to prevent? > I believe a hook that prevents commit times from going backwards or > being ahead of the server time would serve this purpose, but I haven't > investigated in any detail. I'm also not sure off hand how GitHub, > git, and other tools use author vs commit dates. This is something > else that will need more investigation. 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). Also, when a developer wants to push local changes to the remote server, they have to pull remote first. That means a merge of remote branch with local branch. That merge, again, will be according to local time, which may be incorrect. When such a commit is pushed to the remote it may appear out of order in relation to other commits. 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. GrzegorzJ 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. From owner-freebsd-git@freebsd.org Wed May 29 17:58:46 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 21C8215A8DAB for ; Wed, 29 May 2019 17:58:46 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FE8A775D4; Wed, 29 May 2019 17:58:45 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from crayon2.yoonka.com (crayon2.yoonka.com [10.70.7.20]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id x4THwhxW077195 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 May 2019 17:58:43 GMT (envelope-from list1@gjunka.com) Subject: Re: Git handling of commit times To: Ed Maste Cc: freebsd-git@freebsd.org References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> From: Grzegorz Junka Message-ID: <82938a26-892e-0459-aa23-bdcd9e318b6c@gjunka.com> Date: Wed, 29 May 2019 17:58:43 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB-large X-Rspamd-Queue-Id: 4FE8A775D4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-6.88 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(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:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gjunka.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-3.62)[ip: (-9.47), ipnet: 88.98.192.0/18(-4.74), asn: 56478(-3.79), country: GB(-0.09)]; MX_GOOD(-0.01)[cached: gjunka.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.949,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; 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:58:46 -0000 On 29/05/2019 17:08, Ed Maste wrote: > 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: You mean undesirable cases? Since it's only metadata for git, these are not invalid per se. Also, in both cases below "commit time" means "local time" at the time the commit is being made. Updating timestamp in a commit rehashes that commit. > - commit time is earlier than parent(s) Yeah, sounds pretty easy to check. Should be enough to compare "git show -s --format=%ci HEAD" with local time. That could actually be enough to prompt a developer to update local time if HEAD is recent enough. > - 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). 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). > 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. 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). From owner-freebsd-git@freebsd.org Wed May 29 21:26:26 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 D66AC15AE357 for ; Wed, 29 May 2019 21:26:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 1C39A88933 for ; Wed, 29 May 2019 21:26:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x733.google.com with SMTP id d15so2511714qkl.4 for ; Wed, 29 May 2019 14:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tOMG3nraAGNXjMJolTOjNh+V7N3x4hTfEC1T66f3Gss=; b=SST4RIEDzKAib/WaAoor4vuKBCpR6Xij+BltlFVeKurtz7Xk+zhvbvx+f6aCqOT3sV NF1npkZhmWLjUMEF/JVaGVJwFNBL36HM7F9dLM4yZLTI5e64tT/JRjdttu4sjbMeJBUz gw8YNP49UsIYOIB5EHwk7M4UVqws1C7/YKzCjq22Xde2o4rlFzw3S0cavKHI29iUkPc2 wqQUC9bmpDU9Wi12nC2WXN9IqWvBsJp9Fi2QCmFz1bVNA7PudAAwUxKHzKvSVerPL0Hh C3U3GYz9MoNEWQpdLFFGscTvZEaQt4cc+gIVzvbldAs8uR5gWuSMd9T6gI6PZBflI6Vs ucyg== 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=tOMG3nraAGNXjMJolTOjNh+V7N3x4hTfEC1T66f3Gss=; b=H0n6PSIBssHrL+/6hzzfpUboHDiUqjFVx+TWEO/U0O4xqDIUkDBZey85i15eTFTOML ZOhcdtM6QHjJQIRwDV3Aq8UB3aZ4zmlnmexBH/AgGQjSPlpIFJPenK53Mw4CsJVdWItG p+B731FH+fjdbupdYrYOkmiMv6N8xUukmP1pti3BH0o8NOBGPLcKTV8MPS0emRdHkrSe HVkoCxE9XFbIEKBU/0ISz/Ei2fZXBm5yhHEt+rf+4ejb01afXvIzrPh65xefugyxnYwS /79hPz7OzhRymROqy7kXTR5D/jsL1UBzOUiHNUbpamEgWVK8tcA9ycUKnJKvcSYN/jXD ZBZA== X-Gm-Message-State: APjAAAWye9+mgrISOBpAeKS3wY0Q8nZh02MqCd8Y4NepaSIImQB+/Eju DSthFUtrmJ2hUj6/kuShkeHHcBjWWww42V6KS6+FzA== X-Google-Smtp-Source: APXvYqx1PXPflleso6Bp49PkTKWVSr6ikeClAwVItjT2wf/dyp0z2Cpy9tZaUEqDEev0F2Py1z944kqxNtKcJRguVMI= X-Received: by 2002:a37:4b48:: with SMTP id y69mr2300qka.77.1559165184269; Wed, 29 May 2019 14:26:24 -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: Warner Losh Date: Wed, 29 May 2019 15:26:13 -0600 Message-ID: Subject: Re: Git handling of commit times To: Ed Maste Cc: Grzegorz Junka , freebsd-git@freebsd.org X-Rspamd-Queue-Id: 1C39A88933 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=SST4RIED X-Spamd-Result: default: False [-5.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[3.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.96)[-0.956,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-3.02)[ip: (-9.42), ipnet: 2607:f8b0::/32(-3.32), asn: 15169(-2.30), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 21:26:26 -0000 On Wed, May 29, 2019 at 12:27 PM Ed Maste wrote: > 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. > I think this is not a viable position to stake out. The very simple work flow of git branch -b foo hack git commit