Hi! On Mon, Dec 16, 2019 at 10:53:05AM +0100, Mark Wielaard wrote: > On Fri, 2019-12-06 at 17:44 +0300, Maxim Kuvyrkov wrote: > > > On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> > > > wrote: > > > > On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists) > > > > <richard.earns...@arm.com> wrote: > > > > > > > > Monday 16th December 2019 - cut off date for picking which git > > > > conversion to use > > > > > > > > Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage > > > > 3. > > > > > > > > Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes > > > > on line for live commits. > > > > > > I have regenerated my primary version this week, and it's up at > > > https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ . > > > So far I have received only minor issue reports about it, and all known > > > problems have been fixed. > > > I could use a bit more scrutiny :-). > > > > I think now is a good time to give status update on the svn->git conversion > > I maintain. > > See https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ . > > > > 1. The conversion has all SVN live branches converted as branches under > > refs/heads/* .
That is true as far as I can see. All branches I care about are there, at least, and I don't see anything missing. > > 2. The conversion has all SVN live tags converted as annotated tags under > > refs/tags/* . Yup. > > 3. If desired, it would be trivial to add all deleted / leaf SVN branches > > and tags. > > They would be named as branches/my-deleted-branch@12345, > > where @12345 is the revision at which the branch was deleted. > > Branches created and deleted multiple times would have separate entries > > corresponding to delete revisions. I don't think this is desirable. > > 4. Git committer and git author entries are very accurate > > (imo, better than reposurgeon's, but I'm biased). > > Developers' names and email addresses are mined from commit logs, > > changelogs and source code and have historically-accurately attributions > > to employer's email addresses. They are very good, yes. I have verified this *a lot*, months ago. This was all ready to go before the Cauldron. > > 5. Since there is interest in reparenting branches to fix cvs2svn merge > > issues, > > I've added this feature to my scripts as well (turned out to be trivial). > > I'll keep the original gcc-pretty.git repo intact and will upload the > > new one at > > https://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/ > > -- should be live by Monday. > > Should we go with the gcc-reparent.git repo now? I don't actually know what the difference is. As far as I understand it changes nothing for anything from this century, so either is fine with me. And it is not very useful to have this old history cleaned up a bit: the really *big* problem with the old history is that a) people did omnibus commits a lot, not small self-contained commits changing one thing only; and b) we really need to have the motivation that goes with those patches, but that is not available (no mail archives). > Where exactly should it be installed under https://gcc.gnu.org/git/ > Replacing the existing gcc.git will be confusing, but then how would we > name the repo that will become the main git gcc repo in 2 weeks? I think we should rename the old gcc.git mirror. That pain is temporary. > Where are the tools/scripts that should be installed on gcc.gnu.org to > keep it up to date during the next 2 week transition period? I think Maxim mentioned it before, but it's hard to find in this humonguous thread :-) Segher
