threads / discuss / 21178

Merging non-git releases of a project

Subject: Merging non-git releases of a project

## tl;dr

9 messages between Oct 9, 2009 and Oct 11, 2009.

replies: 8people: 4as markdown or json

Howard Miller· Oct 9, 2009, 21:11 UTC · lore

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!
Avery Pennarun· Oct 9, 2009, 21:27 UTC · re: Howard Miller · lore

Re: Merging non-git releases of a project

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
Howard Miller· Oct 9, 2009, 21:33 UTC · re: Avery Pennarun · lore

Re: Merging non-git releases of a project

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>:
Show 41 quoted lines
> 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
>
Avery Pennarun· Oct 9, 2009, 22:43 UTC · re: Howard Miller · lore

Re: Merging non-git releases of a project

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

Show 6 quoted lines
> 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
Peter Baumann· Oct 10, 2009, 08:47 UTC · re: Avery Pennarun · lore

Re: Merging non-git releases of a project

On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
Show 15 quoted lines
> 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.
Björn Steinbrink· Oct 10, 2009, 09:00 UTC · re: Peter Baumann · lore

Re: Merging non-git releases of a project

On 2009.10.10 10:47:42 +0200, Peter Baumann wrote:
Show 10 quoted lines
> 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
Peter Baumann· Oct 10, 2009, 10:04 UTC · re: Björn Steinbrink · lore

Re: Merging non-git releases of a project

On Sat, Oct 10, 2009 at 11:00:53AM +0200, Björn Steinbrink wrote:
Show 14 quoted lines
> 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
Howard Miller· Oct 10, 2009, 08:58 UTC · re: Avery Pennarun · lore

Re: Merging non-git releases of a project

2009/10/9 Avery Pennarun <apenwarr@gmail.com>:
Show 22 quoted lines
> 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.
Avery Pennarun· Oct 11, 2009, 15:32 UTC · re: Howard Miller · lore

Re: Merging non-git releases of a project

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

← back to recent threads