Joseph Myers <jos...@codesourcery.com> writes: > On Thu, 16 May 2019, Maxim Kuvyrkov wrote: > >> Let's avoid mixing the two discussions: (1) converting svn repo to git >> (and getting community consensus to switch to git) and (2) deciding on >> which branches to keep in the new repo. >> >> 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. > > A prerequisite of a move to git is to have policies on branch deletion / > force-pushes, and hook implementations that ensure those policies are > followed (as well as implementing what's agreed on commit messages, > Bugzilla updates, etc.). There has of course been a lot of past > discussion of those that someone will need to find, read and describe the > issues and conclusions from. I think there was a view that branch > deletion and force-pushes should be limited to a particular namespace for > user branches.
We're not starting from scratch on that though. The public git (semi-)mirror has been going for a long time, so IMO we should just inherit the policies for that. (Like you say, forced pushed are restricted to the user namespace.) Policies can evoluve over time :-) Agreeing on a format for commit messages would be good, but IMO it's a separate improvement to the repo discussion. We don't have an agreed format for SVN commit messages either, and although it's not ideal, it doesn't make SVN unworkable. The same would be true for git. Whatever policy we come up with can't apply retrospectively anyway, so the full git history is always going to have a mixture of styles. And I think that's the major downside of putting so many barriers in the way of the conversion. Switching to git without new commit message guidelines might not be perfect, but if we'd done it two years ago anyway, people would have been committing (mostly) git-friendly commits since then, even if the messages weren't very consistent. Whereas at the moment, many commit messages are neither git-friendly nor consistent. And that's going to continue to be the case until we switch. So although the intention of these requirements seems to be to make the final git history as good as it can be, I think in practice it's having the opposite effect. > (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 > 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.) But the discussion upthread seemed to be that having the very old stuff in git wasn't necessarily that important anyway. 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. E.g. having proper author names seems like a nice-to-have rather than a requirement. A lot of the effort spent on compiling that list seemed to be getting names and email addresses for people who haven't contributed to gcc for a long time (in some cases 20 years or more). It's interesting historical data, but in almost all cases, the email addresses used are going to be defunct anyway. 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. 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. 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. Thanks, Richard