Date: Tue, 1 Oct 2019 09:39:27 -0400 From: Ed Maste <emaste@freebsd.org> To: Ryan Stone <rysto32@gmail.com> Cc: Warner Losh <imp@bsdimp.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: <CAPyFy2BX_md=RdtkAppmRoekXCAp-zWggPmeYLt_f%2Bz3sYsOHw@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, 30 Sep 2019 at 15:17, 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. Thanks Ryan. So that can be used to trivially accommodate changed hashes in a merge-workflow long-lived downstream project (with the downside that two copies of every commit after the divergence will appear in vanilla `git log`). For a rebase-workflow branch `git rebase --onto` can be used to move commits across a set of changed hashes. For example, assuming we have a branch with commits on top of on origin/master they can be moved to origin/svn_head via: git rebase --onto origin/svn_head origin/master
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2BX_md=RdtkAppmRoekXCAp-zWggPmeYLt_f%2Bz3sYsOHw>