From: Howard Miller <hidden> Date: 2016-06-15 22:47:30
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!
On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller
[off-list ref] 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
From: Howard Miller <hidden> Date: 2016-06-15 22:47:30
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 [off-list ref]:
On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller
[off-list ref] wrote:
quoted
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
On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
[off-list ref] 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
From: Peter Baumann <hidden> Date: 2016-06-15 22:47:30
On Fri, Oct 09, 2009 at 06:43:50PM -0400, Avery Pennarun wrote:
On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
[off-list ref] wrote:
quoted
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.
From: Howard Miller <hidden> Date: 2016-06-15 22:47:30
2009/10/9 Avery Pennarun [off-list ref]:
On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
[off-list ref] wrote:
quoted
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.
On Sat, Oct 10, 2009 at 4:58 AM, Howard Miller
[off-list ref] 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