On Tue, 2015-09-01 at 06:54 -0400, Eric S. Raymond wrote: > With the machinery for the git conversion now in reasonable shape, it's > time to ask GCC's developers in general: what do you want this > conversion to accomplish? > > There are some obvious things we might expect it to accomplish, like > > (1) Encouraging people to do finer-grained commits because the operation is > so much faster.
FWIW, I'm not convinced (1) is so relevant to gcc. For me, most of my time spent on committing patches to gcc is the part where I'm waiting on my machine to do bootstrap®ression testing; the actual commit is relatively fast. I believe we have a policy that although we may break up patches into chunks for ease of review, commits themselves should be "atomic", so that the repository is always in a working state. At least, that's the ideal :) > (2) Attract developers who think Subversion is clunky and old-fashioned. Yes, though I think many of us do almost all of our gcc work using git already, using the git-svn mirror, and only touch svn for the final commit. Hence I think this is more a marketing "smell" thing: potential developers may see "SVN" on our website and go "ugh! gcc is so old fashioned!", but the reality for me is that I can already do almost all of my gcc work in git without touching svn. > (3) Enable bisection as a bug-localization technique. > But there's not much Jason or I can do to advance *those* goals; any > conversion except one that's too crappy to be usable would accomplish them. > > What I'm interested in, as I assist the process, is how your desires > ought to affect what we do during the conversion. > > As a trivial example of the possibilities, sometimes when I do conversions > I fix obvious comment typos. I generally have to edit the comment history > anyway > to tweak comments that don't have git-style summary lines into shape, so > fixing typos is not much additional work. > > What kind of mechanical transformation or hand-editing would add value for > you? Will the resulting git commits have some kind of metadata identifying the corresponding SVN revision? For example, I see something like this in the git svn mirror e.g. this line shows up for 0c0caab66d411b8df6a9057d788f1c8bcf77a83a: git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@226697 138bc75d-0d04-0410-961f-82ee72b054a4 We have numerous references to specific revisions in bugzilla and in the list archives, so retaining this mapping seems very useful for future "archaeological digs"; it would be a major regression compared to the git-svn mirror if we lost them. Similarly, our bugzilla automatically turns text like "r226697" into links to the relevant commit in SVN. I don't know if there's a way to maintain those links for git (beyond e.g. creating a named tag for every r[0-9]+, but that's clearly insane), so presumably we'd want to keep the old SVN web interface around to service those bugzilla URLs? I'd love it if the commits gained readable titles (where they don't already). For example, if I run "git shortlog" (on a working copy from the git-svn mirror), I see this for some of my commits: 2013-08-06 David Malcolm <dmalc...@redhat.com> 2013-08-07 David Malcolm <dmalc...@redhat.com> 2013-08-07 David Malcolm <dmalc...@redhat.com> 2013-08-07 David Malcolm <dmalc...@redhat.com> 2013-08-07 David Malcolm <dmalc...@redhat.com> 2013-08-13 David Malcolm <dmalc...@redhat.com> gcc/testsuite gcc/testsuite (etc) which is less than helpful. Since I noticed this, I've been trying to add decent title lines to my SVN commits so that they show up nicely in git. So it'd be great if a script could identify those commit titles that are just the top of ChangeLog entries, scrape the gcc-patches mailing list archives for try to locate the Subject lines of the pertinent patches (and clean away extraneous [PATCH] or [PING] fragments, though other fragments may be pertinent e.g. identifying subsystems). Potentially it could also add the URL of the discussion in the list archive. Clearly a non-trivial task though. Thanks; hope this is constructive Dave