summaryrefslogtreecommitdiff
path: root/Documentation/howto/revert-a-faulty-merge.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/howto/revert-a-faulty-merge.txt')
-rw-r--r--Documentation/howto/revert-a-faulty-merge.txt6
1 files changed, 5 insertions, 1 deletions
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 6fd711996a..075418eeeb 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/Documentation/howto/revert-a-faulty-merge.txt
@@ -7,6 +7,10 @@ Abstract: Sometimes a branch that was already merged to the mainline
after the offending branch is fixed.
Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org>
References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
+Content-type: text/asciidoc
+
+How to revert a faulty merge
+============================
Alan <alan@clueserver.org> said:
@@ -160,7 +164,7 @@ merged. So it's debugging hell, because now you don't have lots of small
changes that you can try to pinpoint which _part_ of it changes.
But does it all work? Sure it does. You can revert a merge, and from a
-purely technical angle, git did it very naturally and had no real
+purely technical angle, Git did it very naturally and had no real
troubles. It just considered it a change from "state before merge" to
"state after merge", and that was it. Nothing complicated, nothing odd,
nothing really dangerous. Git will do it without even thinking about it.