[MacPorts] WorkingWithGit modified

[MacPorts]

Page "WorkingWithGit" was changed by cal at macports.org
Diff URL: <https://trac.macports.org/wiki/WorkingWithGit?action=diff&version=17>
Revision 17
Comment: Document git stash for rebasing, add anchors for direct linking
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: WorkingWithGit
=========================================================================
--- WorkingWithGit (version: 16)
+++ WorkingWithGit (version: 17)
@@ -44,7 +44,7 @@
 
 == Common `git` tasks while working with MacPorts base ==
 
-=== Checking out a working copy ===
+=== Checking out a working copy === #clone
 The source code of MacPorts itself is no longer managed in the same repository as all ports. Contrary to Subversion, checking out a sub-directory of a repository is not possible with Git. In order to avoid that all port maintainers have to clone the complete history of MacPorts base as well, the Subversion repository has been split into multiple separate repositories. MacPorts base is now available using
 {{{
 git clone git at github.com:macports/base.git # or
@@ -53,7 +53,7 @@
 
 See the [#reposplit section on repository splitting during the export] to get an overview of where a path in the old Subversion history is now available in Git.
 
-=== Committing changes in your working copy ===
+=== Committing changes in your working copy === #commit
 A fundamental difference between Subversion and Git working copies is that `svn commit` by default commits all changes in your working copy, but `git commit` by default commits none. Git uses a staging area called "index" that allows you to mark changes for inclusion in the next commit. To add changes to the next commit, use
 {{{
 git add <filename>...
@@ -84,7 +84,7 @@
 
 Note that the push will fail if the remote repository has new changes. Contrary to Subversion, it does not matter whether your changes conflict with the remote ones. If this happens, you must update your local working copy as described in the [#updating section on fetch the latest changes] and re-try the push.
 
-=== Merge a single change from master into a release branch ===
+=== Merge a single change from master into a release branch === #cherrypick
 The equivalent to Subversion's `svn merge -c <revision> .` is `git cherry-pick`. Use `git cherry-pick` to apply a single change from master to a release branch. To do this, look up the commit ID of the commit you want to pick:
 {{{
 git log
@@ -152,6 +152,7 @@
 git pull --rebase
 }}}
 
+'''Note:''' `git rebase` requires that you do not have uncommitted modifications in your working copy. If you have modifications, you can temporarily save them using `git stash` and restore them after the rebase using `git stash pop`.
 '''Warning:''' `git pull` without the `--rebase` flag is a shorthand for `git fetch && git merge origin/master`, which will automatically create a merge commit if it thinks that's necessary.
 
 === Commit messages === #commitmessages
@@ -164,8 +165,6 @@
  1. Use the imperative mood in the subject line
  1. Wrap the body at 72 characters
  1. Use the body to explain what and why vs. how
-
-
 
 === Repository split === #reposplit
 
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://trac.macports.org/wiki/WorkingWithGit>
MacPorts <https://www.macports.org/>
Ports system for OS X

This is an automated message. Someone added your email address to be
notified of changes on 'WorkingWithGit' page.
If it was not you, please report to .