Date: Tue, 1 Oct 2019 09:48:04 -0400 From: Ed Maste <emaste@freebsd.org> To: Warner Losh <imp@bsdimp.com> 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: <CAPyFy2DBV=joxZ6L9NeQUUMGak2nScRnym1Jsbnkk8NuDo%2BLXA@mail.gmail.com> In-Reply-To: <CANCZdfpOhqJKxDJ_8xYnzrm3_sTKftgeE8e50pmUGPZq1wE-ng@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. > 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2DBV=joxZ6L9NeQUUMGak2nScRnym1Jsbnkk8NuDo%2BLXA>