Bug #70695 for Git-FastExport: git-stitch-repo creates unnecessary branches when joining two repositories

This may just be user error... Perhaps I should just ignore the tags / branches marked -N. I was just confused by them appearing when otherwise the tags are re-joined in the stitched repo.

On Fri Sep 02 09:45:57 2011, jamesblackburn@gmail.com wrote: Show quoted text
Thanks for the very complete report. I haven't found time yet to reproduce your steps, and it's been a while since I coded this. I will try to find some time, and make an opinion on the issue. Thanks again, -- BooK

On Tue Sep 06 18:13:49 2011, BOOK wrote: Show quoted text
I finally took a little time to look at the issue. The core of the issue is how git-stitch-repo selects where to attach a commit. At some point it picks the "wrong" branch (i.e. not master) on repo B to attach a commit from repo A's master. After that, it is impossible to reconnect both histories. Right now, the algorithm for attaching commits is very coarse-grained. If there are several options, the current options are to pick the (chronologically) first or last commit from the available options, or to pick one at random. Debugging your repositories with first and last, I get the wrong answer both times, because sometimes the "right" commit is the first, and sometimes it's the last. Given how little information there is when making the decision, there's very little that can be done with the current system[*]. In the last few days, I've been exploring a way to improve the decision-making. This might lead to a proper fix. -- BooK [*] Actually, you could pick the "random" selection algorithm and repeat until the result looks right, but the likelyhood of it making the right choice at every point is going to be smaller and smaller with the size of the repositories.

On Tue, Jun 02, 2015 at 04:10:31PM -0400, dag@cray.com via RT wrote: Show quoted text
Not much progress. I had an idea on how to deal with this, but never went through. I'm still interested in fixing this, so we could try to work on this together. Are the SVN repositories public? -- Philippe Bruhat (BooK) The best of intentions must still have directions. (Moral from Groo The Wanderer #95 (Epic))

On Thu, Jun 04, 2015 at 01:25:57PM -0400, dag@cray.com via RT wrote: Show quoted text
I was expecting that, given your email domain. ;-) Show quoted text
So, the issue is that when there's a branch in repo A and we need to attach a commit from repo B (assuming the commit from B is part of the current "master" branch), the candidate from A is picked mostly at random. I turns out that if the commit from B is on the master branch and the commit selected from A is on a dead branch (i.e. not merged into the final "master" for A), we end up with the master from B diverging from the master from A. Which is not the desired outcome. At the moment, I use a 1-pass algorithm that reads the history from both repositories as a stream, starting from the oldest commits. But to make the right decision at those crossroads, one needs a global overview of the project: which branches exist in both projects (and will need to be "merged" together), and which commits should be part of that global history. I guess the first step would be to build a small repository set for which we can reproduce the issue. The example repositories I was given are much too big for at-a-glance analysis. In parallel, I need to work on the "second pass", which needs to record which branches each commit belongs to. This is only relevant for branches which exist in both repositories. -- Philippe Bruhat (BooK) All of life is a series of trades. And the more you exchange, the less you have to show for it. (Moral from Groo The Wanderer #4 (Pacific))