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: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Alexandre Oliva wrote:

> I don't see that it does (help).  Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion.  git-svn can do that incrementally, after the fact; I'm not
> sure whether either conversion tool we're contemplating does, but being
> able to undertake such recovery seems like a desirable feature to me.

We should ensure we don't have missing branches in the first place (for 
whatever definition of what branches we should have).  Adding a branch 
after the fact is a fundamentally different kind of operation from 
including one in the conversion, because it comes with an extra constraint 
of not changing any existing commit hashes (even if the missing branch 
were e.g. merged into some existing branch and maybe logically an ideal 
conversion would thus have had different hashes for existing commits).

> Maxim appears to be doing so and finding (easy-to-fix) problems in the
> reposurgeon conversion; it would be nice for reposurgeon folks to
> reciprocate and maybe even point out problems in the gcc-pretty
> conversion, if they can find any, otherwise the allegations of

That's exactly where information on missing branches, tags in 
branches/st/tags appearing as branches, reparented commits appearing as 
merges came from - I examined properties of those conversions by 
comparison to reposurgeon conversions.

Joseph S. Myers

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