This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Acceptance criteria for the git conversion

Joseph Myers <>:
> Indeed.  Ideally the tree objects in the git conversion should have 
> exactly the same contents as SVN commits, and so be shared with the 
> git-svn history to reduce the eventual repository size (except where there 
> are defects in the git-svn history, or the git conversion fixes up cvs2svn 
> artifacts and so some old revisions end up more accurately reflecting old 
> history than the SVN repository does).

I don't think sharing with the git-svn history will be possible.  git-svn
is a terrible whole-history converter; the odds of getting the same
topology out of reposurgeon are basically nil, and the problem of matching
different topologies is quite hard.

I'll be frank; if it's doable at all (which I doubt) I think this is a
*really bad idea* - a complexity hairball with few or no actual benefits.
I'm not willing to even try for it unless demand from the development
group is overwhelming and you're able to wait a long, long time for

> One particular case: we have well-maintained .gitignore files, that might 
> even be more accurate than the svn:ignore properties, and I think the 
> conversion should keep those and disable all smart ignore handling (just 
> discard svn:ignore properties, and pass through the existing .gitignore 
> files (and .cvsignore files)).

This is also not currently possible, but it's not an intrinsically bad
idea. Giving reposurgeon an option to to support it wouldn't be very
		<a href="";>Eric S. Raymond</a>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]