Date: Tue, 1 Oct 2019 12:37:17 -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: <CAPyFy2CHR4r3WFbrrPA_vHP18WemmJxNi2b4bfVjUNGtmPnKKQ@mail.gmail.com> In-Reply-To: <CANCZdfqU=YZ5UHCVto_1SW6FknKdAfNKPuY-n6SmLu9Q5xB0DA@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> <CANCZdfqU=YZ5UHCVto_1SW6FknKdAfNKPuY-n6SmLu9Q5xB0DA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Oct 2019 at 10:22, Warner Losh <imp@bsdimp.com> wrote: > > 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 upstr= eam. This is likely different than the last merge point of ours, so I'm unc= lear how this wouldn't bring in extra changes (or blindly say that those re= visions had already been merged). You need to merge in the origin/newhash t= ree 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 so= rt of thing in other projects, and want to make sure that the issues there = don't apply here. Yes, you need to already have the "old" version of the same tree you're going to merge from in place. The full procedure would be something like: % git fetch origin % git diff origin/master origin/svn_head # confirm identical % git merge origin/master % git merge -s ours origin/svn_head > I'll see if this actually works by pushing one of my git svn trees that h= as the different hashes to github and trying to merge our work tree to that= instead of the current FreeBSD upstream. That'd be great, allowing for experimentation with concrete examples.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2CHR4r3WFbrrPA_vHP18WemmJxNi2b4bfVjUNGtmPnKKQ>