Date: Wed, 25 Sep 2019 13:49:58 -0600 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@freebsd.org> Cc: Sean Chittenden <sean@chittenden.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: <CANCZdfoBYwp6Gn9nh754yQGXFR0MWkg3hKo8LF-RX_YgdSBycA@mail.gmail.com> In-Reply-To: <CAPyFy2AWOqtb_DNiekKUx07LbQPzvOkw_qvf58DKuopsvHySTQ@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 25, 2019 at 11:56 AM Ed Maste <emaste@freebsd.org> wrote: > On Wed, 25 Sep 2019 at 10:53, Warner Losh <imp@bsdimp.com> wrote: > > > > But this really was a merge from stable/10 into master, > > I think this is just a question of semantics, not VCS details - I > would argue that it is not a merge in the ordinary sense of the word, > and is certainly not a merge in the git sense. You're right that this > should be represented in history as if it were a cherry pick. Bogusly > adding over 9000 commits to the history is definitely not the "least > wrong" thing the conversion could do. > git log always requires added care. There's not actually 9000 commits there. The tree looks fine topologically. Its purely an artifact of git log. > git log --first-parent isn't really a solution here either, because > there are cases where one legitimately does want history from both > parents, especially working in downstream projects. > I'm pretty sure it would be fine, even in that case. > > I'd offer the opinion that needing to know about things like git log > --first-parent vs having to rebase every single downstream fork, > > We won't need to rebase every fork - in no case should the path > forward be worse than uqs's suggestion of a merge from both old/new > conversions. > IMHO, uqs suggestion is a complete non-starter, at least the "git diff | git patch" one. It destroys all local history, commit messages, etc. Except for the most trivial cases, it's not really going to fly with our users. His other, followup ones might be workable into scripts. I'm not sure you can merge, as there's no common ancestor that's recent enough to give it a chance at succeeding (since the different exports would have different hashes starting fairly early in our history). My experience with qemu is that long-lived merge-updated branches become quite difficult to cope with after a while. It took me three weeks to sort out that relatively simple repo. A rebase has a chance of working for people following a 'rebase' work flow. I can write the scripts to do that because I basically already have them and they just need to be modified to do a 'onto' for the easy to write, but slightly risky case of rebasing them across the chasm to a new point on master (as opposed to rebasing them to the same point on master). The latter is possible, just needs a bit more scripting and wouldn't be too bad to write and the least risky way to update across the chasm for people that don't want to (or can't due to conflicts) jump in the easy but risky way. However, for people like CHERIBSD who follow a 'merge from upstream' model which never rebases (since that would be anti-social to their down streams), I'm having trouble understanding how that could work. At work, we basically do the merge from upstream with collapse model, which I'm having trouble seeing how to move from old hashes to new. I'd like to know what the plan for that would be and would happily test any solution there with a copy of our repo. I'd even be happy to run experiments in advance of there being something more public available to see what options do or don't work. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoBYwp6Gn9nh754yQGXFR0MWkg3hKo8LF-RX_YgdSBycA>