Re: Acceptance criteria for the git conversion

[David Malcolm <dmalcolm at redhat dot com>]

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&regression 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  <dmalcolm@redhat.com>
      2013-08-07  David Malcolm  <dmalcolm@redhat.com>
      2013-08-07  David Malcolm  <dmalcolm@redhat.com>
      2013-08-07  David Malcolm  <dmalcolm@redhat.com>
      2013-08-07  David Malcolm  <dmalcolm@redhat.com>
      2013-08-13  David Malcolm  <dmalcolm@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