Copy branch into master

Hi,

Some time ago I created a DVT branch in my project and I have almost been exclusively working in it. Now the time for some test deployment came and I didn't have time to merge it all back into the master thus I gave out the DVT branch version. 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. How can I do this? Please advise.

Thank you! Ron -- Ron Eggler 1804 - 1122 Gilford St. Vancouver, BC V6G 2P5 (778) 230-9442

On Mon, Nov 28, 2011 at 10:25:33AM -0800, Ron Eggler wrote:

Couple options, depending on what you want:

Rename DVT to master (similar to 'mv DVT master', including losing the contents of 'master'): $ git checkout --detach HEAD $ git branch -M DVT master $ git checkout master

Retain old master (like 'mv master old_master; mv DVT master'): $ git checkout --detach HEAD $ git branch -m master old_master $ git branch -m DVT master $ git checkout master

The "checkout --detach" is just so Git doesn't complain about moving/deleting the currently checked out branch.

If you haven't yet, be sure to read ProGit, which should make questions like this trivial for you to answer yourself in the future: <http://progit.org/book/>

Hope this helps, Andrew

Thanks for that,

I guess I'd go for renaming DVT to master.

However, I also played around with merge a little, started a merge (in Windows GUI) and aborted it but the icon of my directory keeps showing the ywellow exclemation mark, signing that a merge is going on right now but going into the directory, all the files are with a geen check mark. What's going on here? How do I resolve this - I don't wanna mess things up so I might rather resolve this before moving DVT to master.

Thanks, Ron

-----Original Message-----
From: Andrew Eikum [mailto:aeikum@codeweavers.com] 
Sent: Monday, November 28, 2011 10:36 AM
To: Ron Eggler
Cc: git@vger.kernel.org
Subject: Re: Copy branch into master

On Mon, Nov 28, 2011 at 10:25:33AM -0800, Ron Eggler wrote:

I

Couple options, depending on what you want:

Rename DVT to master (similar to 'mv DVT master', including losing the contents of 'master'): $ git checkout --detach HEAD $ git branch -M DVT master $ git checkout master

Retain old master (like 'mv master old_master; mv DVT master'): $ git checkout --detach HEAD $ git branch -m master old_master $ git branch -m DVT master $ git checkout master

The "checkout --detach" is just so Git doesn't complain about moving/deleting the currently checked out branch.

If you haven't yet, be sure to read ProGit, which should make questions like this trivial for you to answer yourself in the future: <http://progit.org/book/>

Hope this helps, Andrew

On Mon, Nov 28, 2011 at 11:08:33AM -0800, 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?

Andrew

No problem, I actually got it all figured out now, and got my branch smoothly merged back into master. Thanks for your help!

Ron

On 11/28/2011 1:30 PM, Ron Eggler wrote:

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

On Tue, Nov 29, 2011 at 2:36 AM, Andrew Eikum <aeikum@codeweavers.com> wrote:

It might not be wise to take the strict definition of rename = move (copy + delete). You will lose *all* your reflog associated with master. The old master is gone forever.

Resetting the branch is "safer". It's like pseudo-copying the branch. The reflog for both branches are still around. You can do this with

 # on master
 $ git reset --hard DVT

or

 # not on master
 $ git branch -f master dvt