Re: Merging non-git releases of a project

From: Avery Pennarun <apenwarr@gmail.com>
Date: Oct 9, 2009, 21:27 UTC
Message-ID: <32541b130910091427i7c8a2426hb69a9914aabde8bc@mail.gmail.com>
In-Reply-To: <26ae428a0910091411i39a03650o51163f794b984524@mail.gmail.com>

On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller <howard@e-learndesign.co.uk> wrote:

Show 8 quoted lines

> Here's my dilemma.... I've used git extensively to track modifications
> made to a reasonably large source tree. I do not have access to the
> repository for that project, just a given release. I have now acquired
> the latest version of that project and I want to 'merge' (not sure
> that's the right word in this case) my changes into the new version.
> Then I need to carry on using git for further changes. I think it
> should be simple but I can't get my head around the best way to do
> this.

Find out the commitid of the first commit when you checked in the upstream project into git, and call it C1.

  git checkout -b vendor C1

(replacing C1 with the commitid). This creates a branch called 'vendor' which is for checking in *only* the pristine code provided by the vendor. It also checks out this new branch.

Next, import the new upstream version of the project and commit it to the 'vendor' branch.

Now, switch back to your branch and merge in the vendor changes:

  git checkout master
  git merge vendor

Or, if you want to produce a clean set of patches on top of the vendor version (ie. for submitting the individual patches upstream), you might want something like this instead:

  git rebase vendor

But be careful, rebasing can make a mess of your history and you shouldn't do it unless you have a good reason.

Good luck.

Avery