On Fri, Aug 2, 2019 at 10:41 AM Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> wrote: > > > On Aug 1, 2019, at 11:43 PM, Jason Merrill <ja...@redhat.com> wrote: > > > > On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov > > <maxim.kuvyr...@linaro.org> wrote: > >> > >>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> > >>> wrote: > >>> > >>>> On Jul 16, 2019, at 3:34 PM, Jason Merrill <ja...@redhat.com> wrote: > >>>> > >>>> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov > >>>> <maxim.kuvyr...@linaro.org> wrote: > >>>>> > >>>>> Hi Everyone, > >>>>> > >>>>> I've been swamped with other projects for most of June, which gave me > >>>>> time to digest all the feedback I've got on GCC's conversion from SVN > >>>>> to Git. > >>>>> > >>>>> The scripts have heavily evolved from the initial version posted here. > >>>>> They have become fairly generic in that they have no implied knowledge > >>>>> about GCC's repo structure. Due to this I no longer plan to merge them > >>>>> into GCC tree, but rather publish as a separate project on github. For > >>>>> now, you can track the current [hairy] version at > >>>>> https://review.linaro.org/c/toolchain/gcc/+/31416 . > >>>>> > >>>>> The initial version of scripts used heuristics to construct branch > >>>>> tree, which turned out to be error-prone. The current version parse > >>>>> entire history of SVN repo to detect all trees that start at /trunk@1. > >>>>> Therefore all branches in the converted repo converge to the same > >>>>> parent at the beginning of their histories. > >>>>> > >>>>> As far as GCC conversion goes, below is what I plan to do and what not > >>>>> to do. This is based on comments from everyone in this thread: > >>>>> > >>>>> 1. Construct GCC's git repo from SVN using same settings as current git > >>>>> mirror. > >>>>> 2. Compare the resulting git repo with current GCC mirror -- they > >>>>> should match on the commit hash level for trunk, branches/gcc-*-branch, > >>>>> and other "normal" branches. > >>>>> 3. Investigate any differences between converted GCC repo and current > >>>>> GCC mirror. These can be due to bugs in git-svn or other > >>>>> misconfigurations. > >>>>> 4. Import git-only branches from current GCC mirror. > >>>>> 5. Publish this "raw" repo for community to sanity-check its contents. > >>>> > >>>> Why not start from the current mirror? Perhaps a mirror of the mirror? > >>> > >>> To check that git-svn is self-consistent and generates same commits now > >>> as it was several years ago when you setup the current mirror. > >> > >> Unfortunately, current mirror does not and could not account for rewrites > >> of SVN commit log messages. For trunk the histories of diverge in 2008 > >> due to commit message change of r138154. This is not a single occurrence; > >> I've compared histories only of trunk and gcc-6-branch, and both had > >> commit message change (for gcc-6-branch see r259978). > >> > >> It's up to the community is to weigh pros and cons of re-using existing > >> GCC mirror as conversion base vs regenerating history from scratch: > >> > >> Pros of using GCC mirror: > >> + No need to rebase public git-only branches > >> + No need to rebase private branches > >> + No need to rebase current clones, checkouts, work-in-progress trees > >> > >> Cons of using GCC mirror: > >> - Poor author / committer IDs (this breaks patch statistics software) > >> - Several commit messages will not be the current "fixed" version > >> > >> Thoughts? > > > > I'm still inclined to stick with the mirror. I would expect patch > > statistics software to be able to be taught about multiple addresses > > for the same person. > > Patch tracking software breaks on emails like > <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where > 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name. > > For completeness, I'll generate and upload a repo based on current mirror > with all branches and tags converted. > > In the end, I don't care much to which version of the repo we switch, as long > as we switch.
I think that if we have something clearly better than the current mirror we should use that. rebasing might be a hassle but git should make that reasonably easy - proper instructions how to do that are of course welcome (just add a new remote, adjust all local branches remote and then rebase?). Richard. > -- > Maxim Kuvyrkov > www.linaro.org > > > >
