This is the mail archive of the
mailing list for the GCC project.
Re: Acceptance criteria for the git conversion
- From: "Eric S. Raymond" <esr at thyrsus dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 1 Sep 2015 11:43:43 -0400
- Subject: Re: Acceptance criteria for the git conversion
- Authentication-results: sourceware.org; auth=none
- References: <20150901105414 dot GA30270 at thyrsus dot com> <1441114107 dot 9002 dot 42 dot camel at surprise>
- Reply-to: esr at thyrsus dot com
David Malcolm <firstname.lastname@example.org>:
> > What kind of mechanical transformation or hand-editing would add value for
> Will the resulting git commits have some kind of metadata identifying
> the corresponding SVN revision?
That's what the --legacy option does. I think Jason plans to use it.
I've noted previously that I actually recommend against this based on
previous experience with Subversion conversions. You get a lot of
clutter in the result and demand for such lookups (especially *outside
the specific context of a buglist*) tends to drop off faster than
people expect. But that policy decision isn't mine to make.
> 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?
There is no way to maintain those links for git, so yes, you want to
keep a read-only Subversion instance around.
This also lowers the utility of keeping the legacy-ID in every commit.
> 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.
There was already some discussion of this. If someone else is willing
to digest the gcc-patches archives into committer/date/subject-line
triples I'll see what I can do.
> Thanks; hope this is constructive
Yes, very much the sort of thing I was looking for.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>