Add a note on the consequences of re-writing a repositories history in
"Undoing in Git - Reset, Checkout and Revert/Fixing a mistake by
modifying a commit" and "Modifying your History".
---
I didn't sucessfully get the ruby gems installed on openSUSE 11.2 (problems
installing ultraviolet) so if someone who does have a working environment could
have a look and maybe do a bit of polishing that would be helpful.
.../0_ Redoing_Git_Reset_and_Revert.markdown | 6 +++++-
.../0_Changing_History.markdown | 20 ++++++++++++++++++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown
index b37245d..8b876f2 100644
--- a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown
+++ b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown
@@ -43,7 +43,11 @@ fundamentally different ways to fix the problem:
never do this if you have already made the history public;
git does not normally expect the "history" of a project to
change, and cannot correctly perform repeated merges from
- a branch that has had its history changed.
+ a branch that has had its history changed. If you do re-write
+ a repositories history anyone else who has cloned the
+ repository will need manually correct the problem on their
+ clone see the "RECOVERING FROM UPSTREAM REBASE" section
+ in linkgit:git-rebase[1].
#### Fixing a mistake with a new commit ####
diff --git a/text/25_Changing_Your_History/0_Changing_History.markdown b/text/25_Changing_Your_History/0_Changing_History.markdown
index b569f46..160c838 100644
--- a/text/25_Changing_Your_History/0_Changing_History.markdown
+++ b/text/25_Changing_Your_History/0_Changing_History.markdown
@@ -1,6 +1,22 @@
## Modifying your History ##
-Interactive rebasing is a good way to modify individual commits.
+There are several ways to re-write the history of a repository. All of
+these can cause problems for commits that have already been pushed to a
+remote repository. If you do re-write a repositories history anyone else
+who has cloned the repository will need manually correct the problem on
+their clone see the "RECOVERING FROM UPSTREAM REBASE" section in
+linkgit:git-rebase[1].
-linkgit:git-filter-branch[1] is a good way to edit commits en masse.
+The simplest method is to use "git commit --amend" to modify the last commit.
+This is useful to correct a commit message, or make a simple update to a
+commit before pushing.
+
+Interactive rebasing is a good way to modify multiple commits. Commits can
+be combined by squashing, changed by editing or removed entirely.
+
+linkgit:git-filter-branch[1] is a good way to edit commits en masse. This is
+useful where a whole component needs to be removed from a project. For
+example removing a subsystem which is licenced under an incompatible
+opensource licence. Or it can be used to alter the commit authorship without
+changing the code.
--
1.7.0.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html