Date: Wed, 29 May 2019 23:48:29 -0700 From: Xin Li <delphij@delphij.net> To: Ed Maste <emaste@freebsd.org>, Grzegorz Junka <list1@gjunka.com> Cc: freebsd-git@freebsd.org Subject: Re: Git handling of commit times Message-ID: <321bbbd8-95af-ccab-fde7-f6def8b4176c@delphij.net> In-Reply-To: <CAPyFy2CkyET7v6hTfhv8ZQ=%2BSYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com> References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <CAPyFy2Bqg6m8D6rO%2Bg87Wk74iBYOGfq%2B=t6B_VhUM26mUZXO%2BQ@mail.gmail.com> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> <CAPyFy2CkyET7v6hTfhv8ZQ=%2BSYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bgZ0XI6x3KUlXW79z4yRhPYI34lnfMmit Content-Type: multipart/mixed; boundary="LRteMQGAcXstmUGdVtss018iUJhSvht6b"; protected-headers="v1" From: Xin Li <delphij@delphij.net> Reply-To: d@delphij.net To: Ed Maste <emaste@freebsd.org>, Grzegorz Junka <list1@gjunka.com> Cc: freebsd-git@freebsd.org Message-ID: <321bbbd8-95af-ccab-fde7-f6def8b4176c@delphij.net> Subject: Re: Git handling of commit times References: <8697933A-B813-4088-90B7-A84589C3CD33@freebsd.org> <CAPyFy2Bqg6m8D6rO+g87Wk74iBYOGfq+=t6B_VhUM26mUZXO+Q@mail.gmail.com> <6fb4c8cb-7f59-872e-4de6-a8a02e7c4e29@gjunka.com> <CAPyFy2CkyET7v6hTfhv8ZQ=+SYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com> In-Reply-To: <CAPyFy2CkyET7v6hTfhv8ZQ=+SYM_yyhtBwzM3GfS3funaDBZHQ@mail.gmail.com> --LRteMQGAcXstmUGdVtss018iUJhSvht6b Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/29/19 10:08, Ed Maste wrote: > On Wed, 29 May 2019 at 11:40, Grzegorz Junka <list1@gjunka.com> wrote: >> >> Timestamp alone doesn't give much information. What matters is when th= e >> branch in which the commit was added has been merged with other branch= es >> (shown as merge commits in the history). >=20 > 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. >=20 >> Bear in mind that commits are local (by the virtue of git being >> distributed scm). You can certainly write a git hook that verifies loc= al >> time to be approximately the same as server time and stop the commit i= f >> 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= ). >=20 > 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: >=20 > - commit time is earlier than parent(s) > - commit time is later than the (accurate) server time >=20 > 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. >=20 > The solution to this issue triggering is easy - just make sure the > client has the correct time. Or, have the server perform the required operation (a merge, or a rebase) on behalf of the user, based on CI result, etc. >> 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. >=20 > 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. Assuming the dates are trustworthy (e.g. the merge or rebase was performed by the server), that can be accomplished with e.g. git log --since. Practically, I think it's more useful to do e.g. git log release/11.1..HEAD and I'm not particularly worried if the dates were not that accurate. Cheers, --LRteMQGAcXstmUGdVtss018iUJhSvht6b-- --bgZ0XI6x3KUlXW79z4yRhPYI34lnfMmit Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJc73zBAAoJEEB5f3yV9INPaS0QAK3zU4mNB3fz3ykxkFiVhGyO bChY36hCj8I9PuvP7wVRSQCNj9NiLK5z/3a5DM4wBoUWzburLyDXZZLm3f9lO4c7 nbeejzQ/wSi6Eld552dS4zk6T87YfUQsAuHB9BisTTpIy2vkIv/CHmmi9sqeAKog /oZAzIrt19svUI4Ft0cmwJimNmxIKXwVp/r9s7RVjCOuODTYVDO4bBPw2fxxBc9O lPbdajis0JXGQE0pf3v+mgmplwNylDZR56pziLUVi0EBiUyeAeRtG0KcIqr9DxL1 WD/k1UT2P4BaONz8LN/2a6oUSr5TPK7QLqYI5GVkjGlWSXhenrDrIv7+yPXJ+uZA j1uwk4+/JiPPI4I4vVNV0Mxr0+c4FODTlH61hpFIs1Z/6OqHMJHqG/MsKgemPoYL O/UmvR8Dc6vjVSvkKHJYvLtSn9icovSkSoZ+FQmKJn+E4qAiN7hDMb+fRawSPNKQ IPxBIZSdSi7iBYyvKg1fJ1IftUlmX/g37UGSJTNRzGFFTCLN9ahmSMfLi2Htb27H uJAEkFAox7M699+FAH5545KmlfQCFCN47FiS3wHGYsiTu8XoMEgDELi6rD1wb9Pb MJKviViu7iYVSYo2Wnl0atQeC6OI1kZXwiXp6BBjP0TkrNJB5imk4GAFC4QgsHc7 FXLg3pBIwC4/EUb+RMj8 =R9+V -----END PGP SIGNATURE----- --bgZ0XI6x3KUlXW79z4yRhPYI34lnfMmit--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?321bbbd8-95af-ccab-fde7-f6def8b4176c>