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 j...@polyomino.org.uk
