On Mon, Oct 12, 2009 at 13:55, Howard Miller <howard@xxxxxxxxxxxxxxxxxxx> wrote: > Another how best to do this. > > - I have my project all nicely in git with all the different releases > and versions in there going back years. Happy :-) > > - I have a customer who has heaviliy modified an oldish version of the > software. > > - I have identified the version that they modified and created a > branch in my git repo based on that version (i.e. what they would have > started with before modifying it) That's the branch where you should apply their changes. Let name it "theirs". And I assume your normal branch is called master. > - Their changes where applied to a simple download - no version > control, no nothing. > > I now need to update them to the latest version of the software - can > git help me here or is it all a disaster? You can have it with both merge and rebase. Merge: $ git checkout master $ git merge theirs Now your master contains a tree where their and your changes are mixed. Exactly how they are mixed (IOW, how you resolved conflicts, what exactly have you taken from their tree, etc) is recorded in the merge commit. You can't export this information out of Git repo (so it is readily and simply usable without Git, that is). That's usually not a problem. Rebase: $ git checkout theirs^0 $ git rebase master The rebase can cause conflicts. $ git branch new-theirs $ git checkout new-theirs Now you are on a branch which contains their changes on top of your current development branch. The software as "they" had it is in "theirs". You can export their changes to your *current* tree to anyone as patches. No one can tell anything about where the changes were created in the first place (the "base"), though. That's the major downside of the approach. > PS. To make matters worse - their original is full of expanced CVS > $Id:$ tags so it will look to git like every single file has changed. You can filter them out using you favorite editor or scripting language and commit the filtered tree. Gits merge considers only the final states of the branches it merges. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html