Date: Thu, 10 Oct 2019 14:03:41 -0600 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@freebsd.org> 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: <CANCZdfpnA8OGhGJAWRzfVNnCvvV4SFPP3qXDgUCJjE5Uo3RVLw@mail.gmail.com> In-Reply-To: <CAPyFy2AQ1BDGvpHhZpR9%2Bz1%2BFQWneX8NmULOjrNC3hkpNsjdAA@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> <CAPyFy2AQ1BDGvpHhZpR9%2Bz1%2BFQWneX8NmULOjrNC3hkpNsjdAA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just FYI: netflix% git subtree -P FreeBSD merge bsdimp-zooty-svn/meta-bump fatal: refusing to merge unrelated histories netflix%git subtree -P FreeBSD merge --allow-unrelated-histories bsdimp-zooty-svn/meta-bump error: unknown option `allow-unrelated-histories' ... bsdimp-zooty-svn is a tree that I've been maintaining via git svn. So the hashes are different, even though the deltas are the same. I've not tried a simple 'git merge' yet. It does support --allow-unrelated-histories, but doesn't support the subtree stuff Netflix needs. Needless to say, this is not a happy thing... Warner On Tue, Oct 1, 2019 at 10:51 AM Ed Maste <emaste@freebsd.org> wrote: > 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 > branch as your last merge point, though. I need to test that, though. > Usually a merge is to the top of the thing you are merging, so some caution > is needed. 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, > not the current branch point. This isn't quite what you want in many cases > because 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 > WIPness. For that, it's not at all trivial because maybe 10 of the WIP > trees haven't been merged forward in a while due to conflicts that I've not > had time 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?CANCZdfpnA8OGhGJAWRzfVNnCvvV4SFPP3qXDgUCJjE5Uo3RVLw>