Date: Tue, 1 Oct 2019 08:31:51 -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: <CANCZdfr=tdPie%2BA4jHLK41Empe2meEQruc6XOpStyeTn%2BaZBvw@mail.gmail.com> In-Reply-To: <CAPyFy2BX_md=RdtkAppmRoekXCAp-zWggPmeYLt_f%2Bz3sYsOHw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 1, 2019 at 7:39 AM Ed Maste <emaste@freebsd.org> wrote: > 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`). > 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'.... 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 > 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. And while it's often convenient to do this, if the new changes have merge conflicts, then you have to cope with those or abort the rebase. If you are looking for something that's an exact leap sidewise, it's less trivial to do. And while many people may be able to make the jump forward, we need to have a good story for those that can't. it can be scripted, I'm sure, and we should provide those scripts. 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. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr=tdPie%2BA4jHLK41Empe2meEQruc6XOpStyeTn%2BaZBvw>