Date: Wed, 25 Sep 2019 08:52:54 -0600 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@freebsd.org> Cc: Sean Chittenden <sean@chittenden.org>, freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uspoerlein@gmail.com> Subject: Re: Service disruption: git converter currently down Message-ID: <CANCZdfq71yYjGGog9qm2-xb0RRZG8=YdCg3g0%2BotLvPn6r3xJw@mail.gmail.com> In-Reply-To: <CAPyFy2AMqft2EwdZHYnFUOFxSDOmN1Rv0A9jnR3VdE38SP87pw@mail.gmail.com> References: <CAJ9axoR41gM5BGzT-nPJqqjym1cPYv31dDUwXwi4wsApfDJW%2Bw@mail.gmail.com> <CAJ9axoToynYpF=ZdWdtn_CkkA2nVkgtckQSu%2BcMis1NOXgUdnA@mail.gmail.com> <CAJ9axoR2VXFo9_hx9Z1Qwgs7U-dkan56hrUKO9f7uN6Wpd15xQ@mail.gmail.com> <CAHevUJHwDet8pBdrE4SN3nuoAUgP-ixpCz9uOTdwbE31UDDsbA@mail.gmail.com> <CAPyFy2AMqft2EwdZHYnFUOFxSDOmN1Rv0A9jnR3VdE38SP87pw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 24, 2019 at 7:48 AM Ed Maste <emaste@freebsd.org> wrote: > On Mon, 23 Sep 2019 at 13:51, Sean Chittenden <sean@chittenden.org> wrote: > > > > > > > > Please note however, that more "garbage" metadata escaped from SVN into > > > github, meaning 3rd parties have a hard time re-running the conversion > and > > > making sure that it matches SVN down to the metadata (i.e. timestamps). > > > > > Discussion of a force-push to github has occurred a few times and been > > explicitly ruled out because most of our corporate citizens use github to > > integrate changes from FreeBSD. > > Unfortunately it's not just a few instances of bogus metadata (commit > timestamps and authors), there are also a cases where the git > conversion misrepresents the operation performed and makes for > confusing history. > I'm not sure it's completely wrong... I will absolutely agree, however it's confusing. One example of this is r306097 / df422cbea30e. A file that had been > removed in head needed to be restored, and in SVN it was done by > copying from the stable/10 branch. The git converter interpreted that > as a merge, and then grafted the post-branch stable/10 history into > head as a result. That is why we have a bit over 9000 stable/10 > commits showing up in 'git log origin/master'. > git log --first-parent fixes that, however. Git log's notion of what's sensible to display by default is a poor match to what most people think is sensible. It is a common thing to have to do with other upstreams I track. qemu has this same issue because it merges to the mainline. It's the main reason that I think merge commits to master are evil in a project like ours. It was the best trick I learned when rebasing our sbruno's qemu-bsd-user branch to a 3.1 base. But this really was a merge from stable/10 into master, so we run afoul of a confusing git log default. We did copy the file from stable/10, though in a more ideal world this would be represented as a cherry-pick. git doesn't preserve meta-data for that operation, though (except it can add a note to the commit message that's free form). So representing it as a merge is likely the least worst thing it can do to preserve the metadata (although some would argue that the 'guess about copies' code obviates the need for keeping this data around). I'd offer the opinion that needing to know about things like git log --first-parent vs having to rebase every single downstream fork, the former is several orders of magnitude less pain. We can ensure that there are no back doors by doing a diff at a known good version, seeing know differences with the svn repo and signing the next commit (since it implicitly signs all previous ones), but that is tricky in a dual world and may need to be reserved for the svn read-only flag day that we all know is coming. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq71yYjGGog9qm2-xb0RRZG8=YdCg3g0%2BotLvPn6r3xJw>