Documentation: Refer to git-rebase(1) to warn against rewriting

This points readers at the "Recovering from upstream rebase" warning
in git-rebase(1) when we talk about rewriting published history in the
'reset', 'commit --amend', and 'filter-branch' documentation.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Thomas Rast 2008-09-13 18:11:01 +02:00 committed by Junio C Hamano
parent 90d1c08efc
commit 97c33c6583
3 changed files with 10 additions and 2 deletions

View File

@ -144,6 +144,10 @@ It is a rough equivalent for:
------
but can be used to amend a merge commit.
--
+
You should understand the implications of rewriting history if you
amend a commit that has already been published. (See the "RECOVERING
FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
-i::
--include::

View File

@ -36,7 +36,9 @@ the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
full implications, and avoid using it anyway, if a simple single commit
would suffice to fix your problem.
would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM
REBASE" section in linkgit:git-rebase[1] for further information about
rewriting published history.)
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace

View File

@ -82,7 +82,9 @@ $ git reset --hard HEAD~3 <1>
+
<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
and you do not want to ever see them again. Do *not* do this if
you have already given these commits to somebody else.
you have already given these commits to somebody else. (See the
"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
the implications of doing so.)
Undo a commit, making it a topic branch::
+