On Fri, May 17, 2019 at 09:18:53AM +0100, Richard Sandiford wrote: > Joseph Myers <jos...@codesourcery.com> writes: > > On Thu, 16 May 2019, Maxim Kuvyrkov wrote: > >> With git, we can always split away unneeded history by removing > >> unnecessary branches and tags and re-packing the repo. We can equally > >> easily bring that history back if we change our minds.
Only if we have stored it somewhere! But we all agree we will never delete any (non-user) branches I think. > > (I support a move to git, but not one using git-svn, and only one that > > properly takes into account the large amount of work previously done on > > author maps, understanding the repository peculiarities and how to I am very much **against** most of that author map stuff. It is falsifying history. Replacing the sourceware account name of people by one of their current email addresses is just foolish anyway. In many cases anyone can trivially glance the correct info from the changelogs. In some other cases it is hard or impossible to find the correct info. The information we have now in SVN is what we have there now. We should convert *that* information to Git, nothing more, nothing less. And that is very much possible to do, not a gargantuan task. > > correctly identify exactly which directories are branches or tags, fixing > > cases where there are both a branch and tag of the same name, identifying > > which tags to remove and which to keep, etc.) Yes -- one of the problems I have with the current git-svn mirror is that it doesn't have any of the SVN branches under ibm/ as separate Git branches. It looks like Maxim's scripts will handle this; the conversion hasn't reached those branches yet though. Soon :-) > FWIW, I've been using the "official" git-svn based mirror for at least > the last five years, only using SVN to actually commit. And I've never > needed any of the above during that time. I do look through all history pretty often. The current mirror is good enough for most of that, and there is no way to get the rest back AFAIK. > It would be a really neat project to create a GCC git repo that goes > far back in time and gives the closest illusion possible that git had > been used all that time. And personally I'd be very interested in > seeing that. But its main use would be as a historical artefact, > to show how a long-running software project evolved over time. Agreed. > I think the focus for the development git repo should be on what's > needed for day-to-day work, and like I say, the git-svn mirror we > have now is in practice a good enough conversion for that. If we can > do better then great. But I think we're in serious danger of making the > best the enemy of the good here. Yes. There are a few things that should be fixed though, like that branches vs. tags thing, and the subdir branches problem. > The big advantage of Maxim's approach is that it's a public script in > our own repo that anyone can contribute to. So if there are specific > tweaks people want to make, there's now the opportunity to do that. > > So FWIW, my vote would be for having a window to allow people to tweak > the script if they want to, then make the switch. I agree. Segher
