From: Howard Miller <howard@e-learndesign.co.uk>
Date: Sat, 10 Oct 2009 08:58:01 GMT
Subject: Re: Merging non-git releases of a project
Message-ID: <26ae428a0910100158s5233841byd303377aa20eb45f@mail.gmail.com>
In-Reply-To: <32541b130910091543x19b3b46an109f90be5c5bfaa2@mail.gmail.com>

2009/10/9 Avery Pennarun <apenwarr@gmail.com>:
> On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> 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.
>
> Try this:
>
>   cd mygitproject
>   git rm -rf .
>   cp -a /tmp/wherever/vendor-1.2/. .
>   git add .
>   git commit
>
> Don't worry, git won't double-store files that are identical between
> the old 1.0 and new 1.2 versions.
>
> Avery
>

Adding Unix ignorance to git ignorance... doesn't that delete the .git
directory too?

I don't have cp -a (on a mac) but, IIRC, that's just -rp or somesuch?

But I see, basic idea is to ditch the files, replace them with the new
vendor release a commit. I did think of that but it seemed too simple
:-)

Cheers.