Re: Merging non-git releases of a project

[Howard Miller <howard@e-learndesign.co.uk>]

Hi, Thanks!

I'm missing the point here though. Where/when  do I actually add the
new pristine code? If I checkout, as you suggest, my initial commit I
just have (say) v1.0 of the vendor's code. I can't just copy (say)
version 1.2 on top as the files probably won't match one-one.

Sorry - I'm probably completely failing to understand.

2009/10/9 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
>