From: Alex Riesen <raa.lkml@gmail.com>
To: Howard Miller <howard@e-learndesign.co.uk>
Cc: git@vger.kernel.org
Subject: Re: Merge (or maybe rebase) question
Date: Mon, 12 Oct 2009 20:13:12 +0200 [thread overview]
Message-ID: <81b0412b0910121113l7d084618o6d34fb4a0389421c@mail.gmail.com> (raw)
In-Reply-To: <26ae428a0910120455k7ab5aa5ag8d701050e7acec5f@mail.gmail.com>
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.
prev parent reply other threads:[~2009-10-12 18:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-12 11:55 Merge (or maybe rebase) question Howard Miller
2009-10-12 18:13 ` Alex Riesen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81b0412b0910121113l7d084618o6d34fb4a0389421c@mail.gmail.com \
--to=raa.lkml@gmail.com \
--cc=git@vger.kernel.org \
--cc=howard@e-learndesign.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).