This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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
jsm@polyomino.org.uk