From owner-freebsd-current@freebsd.org Wed Jan 6 05:45:01 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9E3CD4C3B46 for ; Wed, 6 Jan 2021 05:45:01 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4D9dcF2pCPz4kxL; Wed, 6 Jan 2021 05:45:01 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-il1-x12b.google.com with SMTP id r17so2084351ilo.11; Tue, 05 Jan 2021 21:45:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=N1x6QblnwiE2ya+refT0zAzPuMCsOK6DL5FTrawqpv4=; b=DbXPuosoamXzc8TQTRQ0aPP6rdfBMOhTHi2kKJnj4L0N1rubnHpn2UZNVojqu2Ioyt GSkVnTU75c3pg5Utxt0DqDgHMlcLxoVN3iUGSTegbNt4JH37t7Ae/A06mx5Q21mwy/Ie Nxgan0i1on+7u1cRm8d5HWOM9EQ2B6KB7mXBWvGr5bRIIabdkmVRtX3IVD3WT7AMmwl1 DLdo3mQKIEB4248osFZeNWNFWHHP59AsA/QGeLS3aNyJah3jChgEsDCuHn2kZwXe01Se FKab3/BCwjEuEeEzLFOifYjydJkj/3/nXAmm92Hr99bzFUhWkwzUkvIXuS/iWiF877Ag Tzmw== X-Gm-Message-State: AOAM530yvUPWEyk0AArXLeipJFsmnYihOgAtp3ou6ieDkFhXPpJ27bQi BZ0BsPoWSv58JF5CrkqmXBVLGV7gSxI= X-Google-Smtp-Source: ABdhPJyX357khKaSwTTbM2l2tbYsOvTt96Xr87Ww+20xiyVbNn0gvftCnkjZ6xxH1ZlbxS0d67oRLg== X-Received: by 2002:a92:4002:: with SMTP id n2mr2752784ila.293.1609911899509; Tue, 05 Jan 2021 21:44:59 -0800 (PST) Received: from [192.168.2.31] ([71.241.135.42]) by smtp.gmail.com with ESMTPSA id d5sm1212397ilf.33.2021.01.05.21.44.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jan 2021 21:44:58 -0800 (PST) Sender: Theron Tarigo Subject: Re: git non-time-sequential logs To: John Baldwin , John Kennedy , Current FreeBSD References: <3bcdbb72-06bf-e921-b64d-5319405f62bf@FreeBSD.org> From: Theron Message-ID: <2c2da2e2-99a0-e277-a2a6-4a73230f3406@gmail.com> Date: Wed, 6 Jan 2021 00:44:13 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <3bcdbb72-06bf-e921-b64d-5319405f62bf@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4D9dcF2pCPz4kxL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 05:45:01 -0000 On 1/5/21 2:36 PM, John Baldwin wrote: > On 1/4/21 8:52 AM, John Kennedy wrote: >> On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote: >>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust >>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but >>> I'm going to repull all the sources and recompile, just in case. I might >>> have initiall pulled it during the git conversion and maybe it is confused. >> This might be perfectly natural and just new to me, but when I look at the >> git logs this morning I see things like this (editing by me): >> >> commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, freebsd/main, freebsd/HEAD) >> Author: Emmanuel Vadot >> Date: Mon Jan 4 17:30:00 2021 +0100 >> >> commit f61a3898bb989edef7ca308043224e495ed78f64 >> Author: Emmanuel Vadot >> Date: Mon Dec 14 18:56:56 2020 +0100 >> >> commit b6cc69322a77fa778b00db873781be04f26bd2ee >> Author: Emmanuel Vadot >> Date: Tue Dec 15 13:50:00 2020 +0100 >> >> commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf >> Author: Emmanuel Vadot >> Date: Mon Jan 4 16:23:10 2021 +0100 >> >> This is a fresh clone+pull off of anongit@git.FreeBSD.org:src.git. >> >> I've always assumed that the "Date:" there was when the commit happened, >> so they'd be increasing (most recent on top), but I suppose that you might >> have developers in branches that are committing to their branch at one >> point in time and it's getting merged into current (main) later, but the >> original date is preserved? >> >> I guess I only care because I was trying to use time to bisect the >> time I thought the problem might have been introduced. > For commits to gdb (which uses git), the project asks that all series be > rebased via 'git rebase --ignore-date' prior to pushing to master to give > monotonically increasing commit dates. We could do something similar in > FreeBSD either by asking folks to do that explicitly (though I know I > sometimes forget when pushing to gdb myself), or we could avoid direct > pushes to main. One option some folks mentioned on IRC was to have a > separate "staging" branch that developers push to and then have a bot that > does a rebase --ignore-date of that branch to main periodically, though > that opens the question of how to deal with cherry-picks to stable (for > which asking developers to do a rebase --ignore-date prior to pushing is > probably the simpler approach). > > If we did want monotonically increasing dates without having a staging > branch, we could perhaps use a server-side push hook to reject them and > developers would just have to do a rebase --ignore-date before pushing > again. > In the example above, the commit dates *are* monotonically increasing.  The author dates aren't however, and that's what the log shows. Commit dates for direct changes to HEAD (seen in 'git log --first-parent --pretty=fuller' among other methods) seem like a direct replacement for SVN revisions and their timestamps.  Maybe I'm not understanding the problem? To be extra sure commit dates remain monotonic, it would make sense to enforce by rule: - The commit date must not be earlier than the date of the commit's parent. - The commit date must not be in the future. Is there any nonnegligible reason not to impose that as a protection against accidental system time misconfigurations?  In any other circumstance, it would not come into effect anyway?