Re: Merging non-git releases of a project

[Avery Pennarun <apenwarr@gmail.com>]

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