Date: Tue, 1 Oct 2019 12:50:50 -0400 From: Ed Maste <emaste@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Ryan Stone <rysto32@gmail.com>, freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uspoerlein@gmail.com> Subject: Re: Service disruption: git converter currently down Message-ID: <CAPyFy2AQ1BDGvpHhZpR9%2Bz1%2BFQWneX8NmULOjrNC3hkpNsjdAA@mail.gmail.com> In-Reply-To: <CANCZdfr=tdPie%2BA4jHLK41Empe2meEQruc6XOpStyeTn%2BaZBvw@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> <CAFMmRNz-3_MK5ztNcQh1VuGDrMpHsNPJ0BUP9evKrc-j5E0Utw@mail.gmail.com> <CAPyFy2BX_md=RdtkAppmRoekXCAp-zWggPmeYLt_f%2Bz3sYsOHw@mail.gmail.com> <CANCZdfr=tdPie%2BA4jHLK41Empe2meEQruc6XOpStyeTn%2BaZBvw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Oct 2019 at 10:32, Warner Losh <imp@bsdimp.com> wrote: > > I'm pretty sure you'd need to merge to the same svn rev in the new-hash b= ranch as your last merge point, though. I need to test that, though. Usuall= y a merge is to the top of the thing you are merging, so some caution is ne= eded. And all the -s does is accept all our 'conflicts'.... Yes, I've been assuming (and my experiments have been) with an up-to-date origin/master already merged into my working tree, and an up-to-date svn_head that exactly matches origin/master. There are a few different ways this could be done in a non-experimental situation, and we should experiment with various ones before anything is finalized. >> git rebase --onto origin/svn_head origin/master > > kinda. It would rebase the current branch onto the new tip of svn_head, n= ot the current branch point. This isn't quite what you want in many cases b= ecause it will pull in new changes. The --onto arg needs to be the same svn= rev in the new-stream as the current common ancestor of the current branch= and origin/master. Indeed - in my experiments they are one and the same - there are no new changes in origin/master that are not yet in my working tree. I guess the rule of thumb should be that work to address changed upstream hashes should not involve any new changes, and thus cannot have any conflicts. In my experiments that's most easily achieved by starting with everything up-to-date. > So for a single tree, with a single branch, I'll grant trivial. I have 3 = or 4 trees now with a total of about 100 branches in various stages of WIPn= ess. For that, it's not at all trivial because maybe 10 of the WIP trees ha= ven't been merged forward in a while due to conflicts that I've not had tim= e to resolve. I'll grant you even a trivial action multiplied by 100 could extend to a reasonable effort :) However, in any scenario you're going to have significant effort to deal with those 10 WIP trees. If we published both "old" and "new" versions of the conversion for some reasonable period you can choose when you spend the time to update those trees, and then perform the (individually) trivial migration to the new view.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2AQ1BDGvpHhZpR9%2Bz1%2BFQWneX8NmULOjrNC3hkpNsjdAA>