feature. Unless you really need some change that was done on the
master while you were developing on the branch, you don't really need
those merges; just merge once, when you are done with the feature, and
-Bazaar will take care of the rest. Bazaar is much better in this than
-CVS, so interim merges are unnecessary.
+Git will take care of the rest. Git is much better in this than CVS,
+so interim merges are unnecessary.
Or use shelves; or rebase; or do something else. See the thread for
yet another fun excursion into the exciting world of version control.
You may see conflicts in autoload md5sums in comments. Strictly
speaking, the right thing to do is merge everything else, resolve the
conflict by choosing either the master or branch version, then run
-`make -C lisp autoloads' to update the md5sums to the correct master
+'make -C lisp autoloads' to update the md5sums to the correct master
value before committing.
* Re-adding a file that has been removed from the repository
* Undoing a commit (uncommitting)
-If you have not pushed the commit, you may be able to use `git reset
+If you have not pushed the commit, you may be able to use 'git reset
--hard' with a hash argument to revert the your local repo copy to the
pre-commit state.
If you have pushed commit, resetting will be ineffective because it
-will only vanish the commit in your local copy. Instead, use `git
+will only vanish the commit in your local copy. Instead, use 'git
revert', giving it the commit ID as argument. This will create a
new commit that backs out the change. Then push that.
* Bisecting
This is a semi-automated way to find the revision that introduced a bug.
-Browse `git help bisect' for technical instructions.
+Browse 'git help bisect' for technical instructions.
* Maintaining ChangeLog history