Date: Tue, 1 Oct 2019 08:21:55 -0600 From: Warner Losh <imp@bsdimp.com> To: Ryan Stone <rysto32@gmail.com> Cc: Ed Maste <emaste@freebsd.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: <CANCZdfqU=YZ5UHCVto_1SW6FknKdAfNKPuY-n6SmLu9Q5xB0DA@mail.gmail.com> In-Reply-To: <CAFMmRNz-3_MK5ztNcQh1VuGDrMpHsNPJ0BUP9evKrc-j5E0Utw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 30, 2019 at 1:17 PM Ryan Stone <rysto32@gmail.com> wrote: > On Thu, Sep 26, 2019 at 10:27 AM Ed Maste <emaste@freebsd.org> wrote: > > If you try this in a tree with changes (i.e., try applying it to a > > long-running merge-based branch) every modified file will result in a > > conflict, but they can be trivially resolved in favour of the first > > version. From that point on merging from the "new" conversion will > > work as expected. > > You don't have to do this manually. "git merge -s ours > origin/svn_head" will record a merge but will not make any changes to > the local tree. > I'm confused by this. origin/svn_head points to the tip of svn_head upstream. This is likely different than the last merge point of ours, so I'm unclear how this wouldn't bring in extra changes (or blindly say that those revisions had already been merged). You need to merge in the origin/newhash tree at the same svn revision as the current tree to do a zero-change merge. As such, you'd need some automation around this. i've run afoul of this sort of thing in other projects, and want to make sure that the issues there don't apply here. I'll see if this actually works by pushing one of my git svn trees that has the different hashes to github and trying to merge our work tree to that instead of the current FreeBSD upstream. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqU=YZ5UHCVto_1SW6FknKdAfNKPuY-n6SmLu9Q5xB0DA>