Date: Tue, 1 Oct 2019 08:40:22 -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: <CANCZdfqwA9454i25PUew6TBo3iUNT%2BXZeTznx2EH1bLxd4Fcuw@mail.gmail.com> In-Reply-To: <CAPyFy2DBV=joxZ6L9NeQUUMGak2nScRnym1Jsbnkk8NuDo%2BLXA@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> <CANCZdfq71yYjGGog9qm2-xb0RRZG8=YdCg3g0%2BotLvPn6r3xJw@mail.gmail.com> <CAPyFy2AWOqtb_DNiekKUx07LbQPzvOkw_qvf58DKuopsvHySTQ@mail.gmail.com> <CANCZdfoBYwp6Gn9nh754yQGXFR0MWkg3hKo8LF-RX_YgdSBycA@mail.gmail.com> <CAPyFy2C5FNwHOTuamwKQXY9Z_uMJJGnmo_4fG8UOp8expxiN%2BQ@mail.gmail.com> <CANCZdfpOhqJKxDJ_8xYnzrm3_sTKftgeE8e50pmUGPZq1wE-ng@mail.gmail.com> <CAPyFy2DBV=joxZ6L9NeQUUMGak2nScRnym1Jsbnkk8NuDo%2BLXA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 1, 2019 at 7:48 AM Ed Maste <emaste@freebsd.org> wrote: > On Thu, 26 Sep 2019 at 13:26, Warner Losh <imp@bsdimp.com> wrote: > > > > The --first-parent actually mirrors what svn log shows today. What > commits do you think that it omits? > > Right, my comment was in regards to use in my 'wipbsd' merge-based git > branch. A git merge-based workflow is fundamentally not possible with > svn, so what svn log can show isn't all that interesting :) > > What I mean is that I can either git log without --first-parent, and > see all changes including the 9000 "phantom" commits, or I can git log > with --first-parent which excludes those phantom commits, but also > excludes commits I do want to see because when I merge from > upstream/master both parents are important - my work, and new upstream > commits. > You do see all the MERGE commits still, though, with --first-parent. you just don't see all the extra commits they refer to. It excludes the 9000 phantom commits but not the merge point that brings them in. The same would be true of other upstream merges. > > I'll have to try that to see how well it works. I'd not used > allow-unrelated-histories and had frequently run into this issue. In the > past, I'd been warned off using that flag, but I'll give it another try. > > I presume it can cause a lot of grief on truly unrelated trees, but in > this case we have two trees with no commit objects in common, but in > fact do have tree objects in common. > My experience with rebasing our work qemu bsd-user branch suggests that even with the 'common ancestor' there's no end of trouble with you introduce a lot of merges and once you get more than a few hundred (or maybe a few thousand) commits away from a common ancestor, things break down and need careful study... When git works, it's awesome, but when it doesn't, it's a very rough ride and it's fear of that rough ride that has me asking all the questions and wanting to know the exact details. When 1000 downstream trees convert, we don't want more than a couple of them having issues or we'll be overwhelmed and we'll risk alienating our users. > > We basically have an upstream called 'FreeBSD' that we fetch into our > git repo: > [omitted] > > Thanks, so it's basically a regular merge workflow with the added fun > of subtrees; some experimentation is going to be necessary here but I > believe it will be possible to use the same techniques. > Right. The proof is in the pudding, as they say. > Presumably we could publish two ongoing svn2git conversions during an > overlap period (existing, and corrected), as well as a snapshot of > merging existing into ng. A one time merge of that (instead of > FreeBSD/master in your example above) would bridge the gap to the ng > conversion. > I totally agree. It would be trivial to push master-newhash at any time and that would be 100% non-disruptive. I'm less optimistic about having a ng merged thing work, but if it does we can publish. Is there an easy way for me to run the new conversion script to create a stream that won't push to FreeBSD's github upstream automatically? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqwA9454i25PUew6TBo3iUNT%2BXZeTznx2EH1bLxd4Fcuw>