Merging non-git releases of a project

Merging non-git releases of a project

[Howard Miller]

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.

Any pointers appreciated!

Re: Merging non-git releases of a project

[Avery Pennarun]

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

Re: Merging non-git releases of a project

[Howard Miller]

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
>

Re: Merging non-git releases of a project

[Avery Pennarun]

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

Re: Merging non-git releases of a project

[Peter Baumann]

On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
> 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 .

This won't commit deleted files from v1.0 - v1.2. Use git add -A to stage all
modified and deleted files for the next commit.

>    git commit
> 
> Don't worry, git won't double-store files that are identical between
> the old 1.0 and new 1.2 versions.

Re: Merging non-git releases of a project

[Björn Steinbrink]

On 2009.10.10 10:47:42 +0200, Peter Baumann wrote:
> On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
> > Try this:
> > 
> >    cd mygitproject
> >    git rm -rf .
> >    cp -a /tmp/wherever/vendor-1.2/. .
> >    git add .
> 
> This won't commit deleted files from v1.0 - v1.2. Use git add -A to stage all
> modified and deleted files for the next commit.

It will, the "git rm" already cleans the index.

Björn

Re: Merging non-git releases of a project

[Peter Baumann]

On Sat, Oct 10, 2009 at 11:00:53AM +0200, Björn Steinbrink wrote:
> On 2009.10.10 10:47:42 +0200, Peter Baumann wrote:
> > On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
> > > Try this:
> > > 
> > >    cd mygitproject
> > >    git rm -rf .
> > >    cp -a /tmp/wherever/vendor-1.2/. .
> > >    git add .
> > 
> > This won't commit deleted files from v1.0 - v1.2. Use git add -A to stage all
> > modified and deleted files for the next commit.
> 
> It will, the "git rm" already cleans the index.
> 

You are right. I missed the "git" part and read only rm -rf.

-Peter

Re: Merging non-git releases of a project

[Howard Miller]

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.

Re: Merging non-git releases of a project

[Avery Pennarun]

On Sat, Oct 10, 2009 at 4:58 AM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I don't have cp -a (on a mac) but, IIRC, that's just -rp or somesuch?

You can obtain a non-stupid version of 'cp' (as well as 'ls' and
'grep' and 'find' and other useful tools) for your mac by using fink.
But yes.

Have fun,

Avery