git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: git@vger.kernel.org
Cc: 'Andrew Eikum' <aeikum@codeweavers.com>, git@vger.kernel.org
Subject: Re: Copy branch into master
Date: Thu, 01 Dec 2011 13:43:54 -0600	[thread overview]
Message-ID: <4ED7D8FA.5000305@gmail.com> (raw)
In-Reply-To: <CB09450076EA444CA289CDCB995F16A4@bny.us.bosch.com>

On 11/28/2011 1:30 PM, Ron Eggler wrote:
>> Sorry, I have no idea how to use any of the GUI tools. Perhaps your
>> GUI tool has a mailing list where you can ask about merge conflict
>> resolution?
>
> No problem, I actually got it all figured out now, and got my branch
> smoothly merged back into master.
>
That is not what you originally asked for.  What you asked for was:
"Now I would like to copy exactly what I have in that branch back into 
my master to have an exact copy in my master of what got deployed with 
out any changes."  If you did a git-merge then what you did was combine 
master with DVT.  That most likely did not make master equal to DVT.  If 
you run the following git-diff the results will likely show they do not 
match:
$ git-diff --name-only sha1-of-master-after-DVT-merge 
sha1-of-DVT-before-merge-to-master

If you merge branch A into branch B it does not make branch B equal to 
branch A.  It makes branch B a combination of branch B and branch A 
(plus your merge conflict resolutions).  If you truly want to make 
master exactly match DVT then I recommend the following: (I'm assuming 
this is not a superproject containing submodules, and that you are using 
linux.  I am using git 1.7.1.)

(Return master to the state it was in when you asked the question)
(1) git checkout master
(2) git branch BKUP-master-DVT-merge (backup your current post-merge 
master to another branch)
(3) git reset --hard sha1-of-master-before-merge

(Return DVT to the state it was in when you asked the question)
(1) git checkout DVT
(2) git branch BKUP-DVT-B4-merge (backup current DVT if it has new work)
(3) git reset --hard sha1-of-DVT-before-merge

(Make master match DVT exactly)
(1) Use the "vendor branch code drop" method described in the git-rm 
manpage* (see note on permissions below).  (Use the git-archive command 
to create your tarball of DVT for this.)
(2) After "vendor branch code drop" is committed, git-diff --name-status 
master DVT (they should match, ie. no results that matter)
(3) git-tag the resulting commit to make it clear this is the version 
you deployed.

*Note: if you are tracking permissions in git (executable vs. 
non-executable bits) then you will need to accomodate and validate 
permissions in your git-archive and/or ensure permissions are set 
properly before committing your vendor branch code drop.  Otherwise, you 
will have permissions changes that do not exactly match DVT.

I recommend trying the above on a test copy of your repo to verify the 
results are really what you want.
(tar up your repo as root to retain permissions, and untar in test dir)
(repo path = /home/me/MY-REPO)
(1) pwd ( = /home/me)
(2) mkdir test
(3) su root
(4) pwd ( = /home/me)
(5) tar -cvzf MY-REPO.tar.gz MY-REPO/
(6) cd test
(7) mv ../MY-REPO.tar.gz .
(8) tar -xvzf MY-REPO.tar.gz
(test repo path = /home/me/test/MY-REPO)
(9) exit
(10) cd /home/me/test/MY-REPO
(11) try out what I said on test/MY-REPO and then decide if you want to 
do it on the real me/MY-REPO.

If you already have additional commits on master after your master-DVT 
merge then they are backed up in the BKUP-master-DVT-merge branch you 
made earlier.  These commits can then be interactively rebased on your 
remediated master.  (Be aware of any possible unique master-DVT merged 
code the new commits are dependent on.  If so, that code needs to be 
reincorporated instead of being unwittingly lost.)

All the above assumes that others have not already pulled your 
master-DVT merge and based their work on it.  If they have already 
pulled your new master and based work on it then it may be too late for 
this to be practical, or additional steps would be needed for others to 
properly remediate.  I'm assuming you have a known set of developers 
pulling from you.  It is possible for them to interactively rebase their 
new work onto your remediated master and take the merged-master out of 
their history.  (Be aware of any possible unique master-DVT merged code 
the new commits are dependent on.  If so, that code needs to be 
reincorporated instead of being unwittingly lost.)

Hope this helps.

v/r,
neal

  reply	other threads:[~2011-12-01 19:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 18:25 Copy branch into master Ron Eggler
2011-11-28 18:36 ` Andrew Eikum
2011-11-28 19:08   ` Ron Eggler
2011-11-28 19:26     ` Andrew Eikum
2011-11-28 19:30       ` Ron Eggler
2011-12-01 19:43         ` Neal Kreitzinger [this message]
2011-11-29 12:49   ` Tay Ray Chuan

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=4ED7D8FA.5000305@gmail.com \
    --to=nkreitzinger@gmail.com \
    --cc=aeikum@codeweavers.com \
    --cc=git@vger.kernel.org \
    /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).