Git Merging Guide - Revision history

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2013-01-22T01:22:11Z

‎Package Replacement: Funtoo Overlay (branch to branch)

Drobbins: /* Comparing Experimental and Master */

2013-01-22T01:20:15Z

‎Comparing Experimental and Master

Palica at 08:11, 18 November 2012

2012-11-18T08:11:10Z

Drobbins at 22:49, 16 December 2011

2011-12-16T22:49:02Z

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2011-12-16T22:48:23Z

‎Package Replacement: Funtoo Overlay (branch to branch)

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2011-12-16T22:47:10Z

‎Package Replacement: Funtoo Overlay (branch to branch)

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2011-12-16T22:44:51Z

‎Package Replacement: Funtoo Overlay (branch to branch)

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2011-12-16T22:37:15Z

‎Package Replacement: Funtoo Overlay (branch to branch)

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2011-12-16T22:18:47Z

‎Package Replacement: Funtoo Overlay (branch to branch)

Drobbins: /* Package Replacement: Funtoo Overlay (branch to branch) */

2011-12-16T22:18:25Z

‎Package Replacement: Funtoo Overlay (branch to branch)

@@ Line 16: / Line 16: @@
 When merging in funtoo-overlay, we might want to merge things from experimental to master. To do this, first pick a specific package to compare changes:
-<pre>
+<console>
-# cd /root/git/funtoo-overlay
+# ##i##cd /root/git/funtoo-overlay
-# git diff --stat origin/master origin/experimental app-shells/bash
+# ##i##git diff --stat origin/master origin/experimental app-shells/bash
   app-shells/bash/bash-3.1_p17.ebuild   |  150 -------------------------
   app-shells/bash/bash-3.2_p51.ebuild   |  199 ---------------------------------
@@ Line 27: / Line 27: @@
   app-shells/bash/bash-4.1_p9-r1.ebuild |  189 -------------------------------
   app-shells/bash/bash-4.2_p10.ebuild   |    5 +-
-files changed, 2 insertions(+), 1307 deletions(-)</pre>
+files changed, 2 insertions(+), 1307 deletions(-)</console>
 The "----" in the diff above shows that several ebuilds were removed ("----" means many lines were removed) in the experimental branch, and <tt>bash-4.2_p10.ebuild</tt> had slight modifications. This looks like a good candidate for grabbing from experimental to replace entirely what is in master. Here's an example of something that is ''not'' a good candidate for a wholesale replacement:
-<pre>
+<console>
-# git diff --stat origin/master origin/experimental sys-apps/pciutils
+# ##i##git diff --stat origin/master origin/experimental sys-apps/pciutils
   sys-apps/pciutils/Manifest                         |    3 -
   sys-apps/pciutils/files/conf.d-pciparm             |   28 -------
@@ Line 43: / Line 43: @@
   sys-apps/pciutils/pciutils-3.1.8-r1.ebuild         |   76 -------------------
 files changed, 0 insertions(+), 297 deletions(-)
-</pre>
+</console>
 In this example above, <tt>sys-apps/pciutils</tt> had a lot of cleanups in experimental, but the output above indicates that there is a new <tt>pciutils-3.1.8-1.ebuild</tt> in master that is not experimental. If we replace what is in master with that in experimental, we will lose the new ebuild! So we wouldn't want to do a wholesale replacement in this case. Old ebuilds that disappear are cleanups, but new ebuilds that disappear are not. Be sure to pay attention to whether the ebuilds that are being removed are old or new.
@@ Line 49: / Line 49: @@
 Back to our bash example. To inspect changes in more detail to make sure they are acceptable, specify the modified ebuild directly and drop the <tt>--stat</tt> option:
-<pre>
+<console>
-# git diff origin/master origin/experimental app-shells/bash/bash-4.2_p10.ebuild
+# ##i##git diff origin/master origin/experimental app-shells/bash/bash-4.2_p10.ebuild
 diff --git a/app-shells/bash/bash-4.2_p10.ebuild b/app-shells/bash/bash-4.2_p10.ebuild
 index 0c497ea..e603c15 100644
@@ Line 81: / Line 81: @@
          econf \
                  $(use_with afs) \
-</pre>
+</console>
 OK, these look like changes we want to merge into the master branch. Actually, we want to basically 'adopt' all these bash changes into master -- a wholesale import so that <tt>app-shells/bash</tt> in master looks exactly like that in experimental. To do this, we want to wipe out what is currently in the master branch related to <tt>app-shells/bash</tt>, and replace it entirely with the exact contents of <tt>app-shells/bash</tt> in the experimental branch.
@@ Line 87: / Line 87: @@
 This can be done as follows:
-<pre>
+<console>
-# git rm -rf app-shells/bash
+# ##i##git rm -rf app-shells/bash
-# git checkout origin/experimental -- app-shells/bash
+# ##i##git checkout origin/experimental -- app-shells/bash
-</pre>
+</console>
 Now, let's review the changes git made. These are not yet committed:
-<pre>
+<console>
-# git diff --cached --stat
+# ##i##git diff --cached --stat
   app-shells/bash/bash-3.1_p17.ebuild   |  150 -------------------------
   app-shells/bash/bash-3.2_p51.ebuild   |  199 ---------------------------------
@@ Line 104: / Line 104: @@
   app-shells/bash/bash-4.2_p10.ebuild   |    5 +-
 files changed, 2 insertions(+), 1307 deletions(-)
-</pre>
+</console>
 Looks good. These changes are already staged for commit -- notice the <tt>--cached</tt> option above. If you don't use <tt>--cached</tt>, you won't see any changes, because they're already cached for commit. Let's commit them:
-<pre>
+<console>
-# git commit -m "bash updates from experimental"
+# ##i##git commit -m "bash updates from experimental"
-# git push origin master
+# ##i##git push origin master
-</pre>
+</console>
 If we made any local changes to existing files that had not yet been added, and wanted to include those with the commit, we could use the <tt>-a</tt> option with <tt>git commit</tt>, above. Once the commit has been made, you should no longer see anything related to <tt>app-shells/bash</tt> listed when doing a diff of the branches.

@@ Line 5: / Line 5: @@
 The best way to get a quick and dirty understanding of the differences between experimental and master is to do this:
-<pre>
+<console>
-# cd /root/git/funtoo-overlay
+# ##i##cd /root/git/funtoo-overlay
-# git diff --stat origin/master origin/experimental
+# ##i##git diff --stat origin/master origin/experimental
-</pre>
+</console>
 This will show a summary of what modifications where made on a file-by-file basis.

@@ Line 117: / Line 117: @@
 [[Category:Development]]
 [[Category:Featured]]
-[[Category:Tutorials]]
+[[Category:Tutorial]]

← Older revision		Revision as of 22:49, 16 December 2011
Line 114:		Line 114:

	If we made any local changes to existing files that had not yet been added, and wanted to include those with the commit, we could use the <tt>-a</tt> option with <tt>git commit</tt>, above. Once the commit has been made, you should no longer see anything related to <tt>app-shells/bash</tt> listed when doing a diff of the branches.		If we made any local changes to existing files that had not yet been added, and wanted to include those with the commit, we could use the <tt>-a</tt> option with <tt>git commit</tt>, above. Once the commit has been made, you should no longer see anything related to <tt>app-shells/bash</tt> listed when doing a diff of the branches.
		+
		+	[[Category:Development]]
		+	[[Category:Featured]]
		+	[[Category:Tutorials]]

@@ Line 45: / Line 45: @@
 </pre>
-In this example above, <tt>sys-apps/pciutils</tt> had a lot of cleanups in experimental, but the output above indicates that there is a new <tt>pciutils-3.1.8-1.ebuild</tt> in master that is not experimental. If we replace what is in master with that in experimental, we will lose the new ebuild! So we wouldn't want to do a wholesale replacement in this case.
+In this example above, <tt>sys-apps/pciutils</tt> had a lot of cleanups in experimental, but the output above indicates that there is a new <tt>pciutils-3.1.8-1.ebuild</tt> in master that is not experimental. If we replace what is in master with that in experimental, we will lose the new ebuild! So we wouldn't want to do a wholesale replacement in this case. Old ebuilds that disappear are cleanups, but new ebuilds that disappear are not. Be sure to pay attention to whether the ebuilds that are being removed are old or new.
 Back to our bash example. To inspect changes in more detail to make sure they are acceptable, specify the modified ebuild directly and drop the <tt>--stat</tt> option:

@@ Line 29: / Line 29: @@
 files changed, 2 insertions(+), 1307 deletions(-)</pre>
-The "----" in the diff above shows that several ebuilds were removed ("----" means many lines were removed) in the experimental branch, and <tt>bash-4.2_p10.ebuild</tt> had slight modifications. To inspect further, specify the modified ebuild directly and drop the <tt>--stat</tt> option:
+The "----" in the diff above shows that several ebuilds were removed ("----" means many lines were removed) in the experimental branch, and <tt>bash-4.2_p10.ebuild</tt> had slight modifications. This looks like a good candidate for grabbing from experimental to replace entirely what is in master. Here's an example of something that is ''not'' a good candidate for this:
 <pre>

@@ Line 65: / Line 65: @@
 </pre>
-OK, these look like changes we want to merge into the master branch. To do this, we want to wipe out what is currently in the master branch related to <tt>app-shells/bash</tt>, and replace it entirely with the exact contents of <tt>app-shells/bash</tt> in the experimental branch.
+OK, these look like changes we want to merge into the master branch. Actually, we want to basically 'adopt' all these changes into master -- a wholesale import so that <tt>app-shells/bash</tt> in master looks exactly like that in experimental. To do this, we want to wipe out what is currently in the master branch related to <tt>app-shells/bash</tt>, and replace it entirely with the exact contents of <tt>app-shells/bash</tt> in the experimental branch.
 This can be done as follows:
@@ Line 74: / Line 74: @@
 </pre>
-Now, let's review the changes we made:
+Now, let's review the changes git made. These are not yet committed:
 <pre>
 # git diff --cached --stat
@@ Line 88: / Line 88: @@
 </pre>
-Looks good. These changes are already staged for commit -- notice the <tt>--cached</tt> option above. Let's commit them:
+Looks good. These changes are already staged for commit -- notice the <tt>--cached</tt> option above. If you don't use <tt>--cached</tt>, you won't see any changes, because they're already cached for commit. Let's commit them:
 <pre>