Re: Dealing with rewritten upstream
- From
Jay Soffian <jaysoffian@gmail.com>
- Date
- Sep 30, 2011, 23:28 UTC
- Message-ID
- <CAG+J_Dw9Oa=LH1CSE3Dr_B6de8X-SQfrWGbayPy3OD-UqB6siA@mail.gmail.com>
- In-Reply-To
- <CAMOZ1Bu-1hq1UN+UQs9HreR4bhJAoxGFLA=jdW8jgoC9g3DJHQ@mail.gmail.com>
On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten <mfwitten@gmail.com> wrote:
Show 20 quoted lines
>> 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.