{"thread":{"id":"28539","subject":"Dealing with rewritten upstream","startedAt":"2011-09-30T22:09:10Z","lastAt":"2011-10-01T11:34:21Z","messageCount":4,"participants":["Jay Soffian","Michael Witten","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176601","messageId":"CAG+J_DwR4vE6iYt475EM7-VDNi4hG3jhdmXWSbJ04Y9fyHeuLw@mail.gmail.com","threadId":"28539","inReplyTo":null,"subject":"Dealing with rewritten upstream","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-09-30T22:09:10Z","receivedAt":"2011-09-30T22:09:10Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"I have a repo w/over two years of history whose upstream repo is a\ngit-svn mirror.\n\nThe upstream folks recently announced they need to retire the existing\nrepo and replace it with a new repo. The new repo is identical to the\nold repo tree wise (commit for commit), but some of the commits in the\nold repo had incorrect authorship which is corrected in the new repo,\nso the new repo has different commit IDs than the old.\n\n(i.e., it's as if they've run filter-branch --env-filter on the old repo.)\n\nMy repo has many merge points with the old history.\n\nPictorially:\n\n---A---B---C---D---E... new-upstream/master\n\n---a---b---c---d---e... old-upstream/master\n \\ \\ \\\n 1---2---3---4---5 master\n\nThe obvious way do deal with this situation is:\n\n$ git merge -s ours -m \"Splice in new-upstream/master\" E\n\nAre there any other/better options I'm missing?\n\n(Eventually upstream plans to migrate entirely to git, so I can't just\nrun git-svn myself.)\n\nj.\n"},{"id":"176608","messageId":"CAMOZ1Bu-1hq1UN+UQs9HreR4bhJAoxGFLA=jdW8jgoC9g3DJHQ@mail.gmail.com","threadId":"28539","inReplyTo":"CAG+J_DwR4vE6iYt475EM7-VDNi4hG3jhdmXWSbJ04Y9fyHeuLw@mail.gmail.com","subject":"Re: Dealing with rewritten upstream","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-30T23:04:09Z","receivedAt":"2011-09-30T23:04:09Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Sep 30, 2011 at 22:09, Jay Soffian wrote:\n> I have a repo w/over two years of history whose upstream repo is a\n> git-svn mirror.\n>\n> The upstream folks recently announced they need to retire the existing\n> repo and replace it with a new repo. The new repo is identical to the\n> old repo tree wise (commit for commit), but some of the commits in the\n> old repo had incorrect authorship which is corrected in the new repo,\n> so the new repo has different commit IDs than the old.\n>\n> (i.e., it's as if they've run filter-branch --env-filter on the old repo.)\n>\n> My repo has many merge points with the old history.\n>\n> Pictorially:\n>\n> ---A---B---C---D---E... new-upstream/master\n>\n> ---a---b---c---d---e... old-upstream/master\n>    \\       \\       \\\n>     1---2---3---4---5  master\n>\n> The obvious way do deal with this situation is:\n>\n> $ git merge -s ours -m \"Splice in new-upstream/master\" E\n>\n> Are there any other/better options I'm missing?\n>\n> (Eventually upstream plans to migrate entirely to git, so I can't just\n> run git-svn myself.)\n\nSurely, you'd rather have your master rewritten such that the relevant\ncommits of new-upstream/master are used IN PLACE of the corresponding\nold-upstream/master. Have you considered ways to achieve that?\n"},{"id":"176610","messageId":"CAG+J_Dw9Oa=LH1CSE3Dr_B6de8X-SQfrWGbayPy3OD-UqB6siA@mail.gmail.com","threadId":"28539","inReplyTo":"CAMOZ1Bu-1hq1UN+UQs9HreR4bhJAoxGFLA=jdW8jgoC9g3DJHQ@mail.gmail.com","subject":"Re: Dealing with rewritten upstream","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-09-30T23:28:02Z","receivedAt":"2011-09-30T23:28:02Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten wrote:\n>> Pictorially:\n>>\n>> ---A---B---C---D---E... new-upstream/master\n>>\n>> ---a---b---c---d---e... old-upstream/master\n>>    \\       \\       \\\n>>     1---2---3---4---5  master\n>>\n>> The obvious way do deal with this situation is:\n>>\n>> $ git merge -s ours -m \"Splice in new-upstream/master\" E\n>>\n>> Are there any other/better options I'm missing?\n>>\n>> (Eventually upstream plans to migrate entirely to git, so I can't just\n>> run git-svn myself.)\n>\n> Surely, you'd rather have your master rewritten such that the relevant\n> commits of new-upstream/master are used IN PLACE of the corresponding\n> old-upstream/master. Have you considered ways to achieve that?\n\nMy master has over two years of history with its commit-IDs referenced\nin our bug tracker, in old emails, in archived binaries, etc. So no, I\ndo not want to rewrite my master.\n\nNow, if you mean, do I want to use something like replacement refs to\ntry to more cleanly splice the new upstream into my existing master,\nno I haven't really explored that. git-replace isn't very well\ndocumented with examples of its intended use case.\n\nI've considered setting up a new repo at a different URL that is\nrewritten to be based on the new upstream, and migrating to that,\nmaking the old repo read-only.\n\nBut I'm not sure that's worth the trouble. There doesn't seem to be\ntoo much downside to splicing in the new upstream via merge -s ours.\nIt barely increases the repo size since the trees are the same. Maybe\nthere's some other downsides I'm missing.\n\nj.\n"},{"id":"176632","messageId":"B877FF8066FE4EC3A1CFEAF4B00D1E31@PhilipOakley","threadId":"28539","inReplyTo":"CAG+J_Dw9Oa=LH1CSE3Dr_B6de8X-SQfrWGbayPy3OD-UqB6siA@mail.gmail.com","subject":"Re: Dealing with rewritten upstream","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2011-10-01T11:34:21Z","receivedAt":"2011-10-01T11:34:21Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jay Soffian\" \n> On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten \n> wrote:\n>>> Pictorially:\n>>>\n>>> ---A---B---C---D---E... new-upstream/master\n>>>\n>>> ---a---b---c---d---e... old-upstream/master\n>>> \\ \\ \\\n>>> 1---2---3---4---5 master\n>>>\n>>> The obvious way do deal with this situation is:\n>>>\n>>> $ git merge -s ours -m \"Splice in new-upstream/master\" E\n>>>\n>>> Are there any other/better options I'm missing?\n>>>\n>>> (Eventually upstream plans to migrate entirely to git, so I can't just\n>>> run git-svn myself.)\n>>\n>> Surely, you'd rather have your master rewritten such that the relevant\n>> commits of new-upstream/master are used IN PLACE of the corresponding\n>> old-upstream/master. Have you considered ways to achieve that?\n>\n> My master has over two years of history with its commit-IDs referenced\n> in our bug tracker, in old emails, in archived binaries, etc. So no, I\n> do not want to rewrite my master.\n>\n> Now, if you mean, do I want to use something like replacement refs to\n> try to more cleanly splice the new upstream into my existing master,\n> no I haven't really explored that. git-replace isn't very well\n> documented with examples of its intended use case.\n>\n> I've considered setting up a new repo at a different URL that is\n> rewritten to be based on the new upstream, and migrating to that,\n> making the old repo read-only.\n>\n> But I'm not sure that's worth the trouble. There doesn't seem to be\n> too much downside to splicing in the new upstream via merge -s ours.\n> It barely increases the repo size since the trees are the same. Maybe\n> there's some other downsides I'm missing.\n>\nSurely; one method is to simply create a merge between the Old_master and \nNew_master (i.e. have two parallel branches of identical content) at the \npoint where the new approach starts. Git-filter-branch (if used) already \nprovides the ref to the original, so it's easy to create that special merge.\n\nYou have already noted that all the trees for the commits are identical, so \nthe storage overhead is minimal for just the new commit objects (though the \ncognitive overhead can be large for some - plan for often/early \nexplanations!)\n\nI'm presuming that you will have at some point in the past, a common commit \n(it maybe the initial commit), so that there is still a single root.\n\nThe key question is to decide which 'branch' is Parent1, and which is \nParent2 (at the merge) for any history traversals that may be required in \nthe future. After the merge you can rename the branch back to Master if \nrequired (more cognitive discussions..)\n\nThis slightly differs from your original diagram in that you do not have any \none-to-one links between the old and new commits. The date/time would be the \nsame for the old & new so it shouldn't be hard to find one from the other.\n\nPhilip\n"}]}