Merge (or maybe rebase) question

Merge (or maybe rebase) question

[Howard Miller]

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)

- 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?

As usual, any advice much appreciated.

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.
Damn you cvs!!!

Re: Merge (or maybe rebase) question

[Alex Riesen]

On Mon, Oct 12, 2009 at 13:55, Howard Miller <howard@e-learndesign.co.uk> 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.