On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote: >> Pictorially: >> >> ---A---B---C---D---E... new-upstream/master >> >> ---a---b---c---d---e... old-upstream/master >> \ \ \ >> 1---2---3---4---5 master >> >> The obvious way do deal with this situation is: >> >> $ git merge -s ours -m "Splice in new-upstream/master" E >> >> Are there any other/better options I'm missing? >> >> (Eventually upstream plans to migrate entirely to git, so I can't just >> run git-svn myself.) > > Surely, you'd rather have your master rewritten such that the relevant > commits of new-upstream/master are used IN PLACE of the corresponding > old-upstream/master. Have you considered ways to achieve that? My master has over two years of history with its commit-IDs referenced in our bug tracker, in old emails, in archived binaries, etc. So no, I do not want to rewrite my master. Now, if you mean, do I want to use something like replacement refs to try to more cleanly splice the new upstream into my existing master, no I haven't really explored that. git-replace isn't very well documented with examples of its intended use case. I've considered setting up a new repo at a different URL that is rewritten to be based on the new upstream, and migrating to that, making the old repo read-only. But I'm not sure that's worth the trouble. There doesn't seem to be too much downside to splicing in the new upstream via merge -s ours. It barely increases the repo size since the trees are the same. Maybe there's some other downsides I'm missing. j. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html