# Merging non-git releases of a project 9 messages from 2009-10-09 to 2009-10-11. Participants: Howard Miller, Avery Pennarun, Peter Baumann, Björn Steinbrink. Thread: https://gitlist.dev/t/21178 ## Howard Miller, 2009-10-09 21:11 Subject: Merging non-git releases of a project Message-ID: <26ae428a0910091411i39a03650o51163f794b984524@mail.gmail.com> URL: https://gitlist.dev/e/26ae428a0910091411i39a03650o51163f794b984524%40mail.gmail.com ``` 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, 2009-10-09 21:27 Subject: Re: Merging non-git releases of a project Message-ID: <32541b130910091427i7c8a2426hb69a9914aabde8bc@mail.gmail.com> URL: https://gitlist.dev/e/32541b130910091427i7c8a2426hb69a9914aabde8bc%40mail.gmail.com In-Reply-To: <26ae428a0910091411i39a03650o51163f794b984524@mail.gmail.com> ``` On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller 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 ``` ## Howard Miller, 2009-10-09 21:33 Subject: Re: Merging non-git releases of a project Message-ID: <26ae428a0910091433v2c959a70g9bfc6c54382f370d@mail.gmail.com> URL: https://gitlist.dev/e/26ae428a0910091433v2c959a70g9bfc6c54382f370d%40mail.gmail.com In-Reply-To: <32541b130910091427i7c8a2426hb69a9914aabde8bc@mail.gmail.com> ``` 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 : > On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller > 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, 2009-10-09 22:43 Subject: Re: Merging non-git releases of a project Message-ID: <32541b130910091543x19b3b46an109f90be5c5bfaa2@mail.gmail.com> URL: https://gitlist.dev/e/32541b130910091543x19b3b46an109f90be5c5bfaa2%40mail.gmail.com In-Reply-To: <26ae428a0910091433v2c959a70g9bfc6c54382f370d@mail.gmail.com> ``` On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller 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 ``` ## Peter Baumann, 2009-10-10 08:47 Subject: Re: Merging non-git releases of a project Message-ID: <20091010084742.GB17220@m62s10.vlinux.de> URL: https://gitlist.dev/e/20091010084742.GB17220%40m62s10.vlinux.de In-Reply-To: <32541b130910091543x19b3b46an109f90be5c5bfaa2@mail.gmail.com> ``` On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote: > On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller > 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. ``` ## Howard Miller, 2009-10-10 08:58 Subject: Re: Merging non-git releases of a project Message-ID: <26ae428a0910100158s5233841byd303377aa20eb45f@mail.gmail.com> URL: https://gitlist.dev/e/26ae428a0910100158s5233841byd303377aa20eb45f%40mail.gmail.com In-Reply-To: <32541b130910091543x19b3b46an109f90be5c5bfaa2@mail.gmail.com> ``` 2009/10/9 Avery Pennarun : > On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller > 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. ``` ## Björn Steinbrink, 2009-10-10 09:00 Subject: Re: Merging non-git releases of a project Message-ID: <20091010090053.GA4843@atjola.homenet> URL: https://gitlist.dev/e/20091010090053.GA4843%40atjola.homenet In-Reply-To: <20091010084742.GB17220@m62s10.vlinux.de> ``` 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 ``` ## Peter Baumann, 2009-10-10 10:04 Subject: Re: Merging non-git releases of a project Message-ID: <20091010100458.GC17220@m62s10.vlinux.de> URL: https://gitlist.dev/e/20091010100458.GC17220%40m62s10.vlinux.de In-Reply-To: <20091010090053.GA4843@atjola.homenet> ``` 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 ``` ## Avery Pennarun, 2009-10-11 15:32 Subject: Re: Merging non-git releases of a project Message-ID: <32541b130910110832t7e0b84adt806035bf151a16a0@mail.gmail.com> URL: https://gitlist.dev/e/32541b130910110832t7e0b84adt806035bf151a16a0%40mail.gmail.com In-Reply-To: <26ae428a0910100158s5233841byd303377aa20eb45f@mail.gmail.com> ``` On Sat, Oct 10, 2009 at 4:58 AM, Howard Miller 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 ```