chiark / gitweb /
Terminology: Change "rewind" to "rewrite" where appropriate
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Thu, 5 Sep 2019 10:26:16 +0000 (11:26 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 2 Feb 2020 16:38:22 +0000 (16:38 +0000)
In #928473, Colin Watson writes:
>   the use of "rewind" as a synonym for "non-fast-forwarding", while
> somewhat common in git terminology, is unfortunate.  The terms seem
> to be borrowed from video playback systems, where "rewind" is often
> just the exact opposite of "fast-forward", and so when I see
> "rewinding history" in a few places in dgit(1) my initial
> interpretation is that it must mean "updating a ref to point to an
> ancestor of the commit that it previously pointed to", whereas I
> think dgit(1) means "any push that isn't a fast-forward".  I don't
> know if I'm the only one for whom it has that connotation.

This makes sense.  So, I am changing uses of "rewind" which do not
mean precisely going back to an ancestor.

I think we can often use the word "rewrite" for the more general
case, but there are some places where another wording is better.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
dgit
dgit.1
git-debrebase.1.pod
infra/dgit-repos-server

diff --git a/dgit b/dgit
index 716cecfd5febfbd7452229a8caa2e99c890ce146..b035e108ebc9825ceebe58b0acab06228efebf28 100755 (executable)
--- a/dgit
+++ b/dgit
@@ -4604,7 +4604,7 @@ END
                " of the archive's version.\n".
                "To overwrite the archive's contents,".
                " pass --overwrite[=VERSION].\n".
-               "To rewind history, if permitted by the archive,".
+               "To rewrite history, if permitted by the archive,".
                " use --deliberately-not-fast-forward.";
        }
     }
diff --git a/dgit.1 b/dgit.1
index 9de679dbe10a881353e0bede6d1205dc27f99dcc..cdf3af5c188492edad5fd27eaa1091b547dc1bef 100644 (file)
--- a/dgit.1
+++ b/dgit.1
@@ -792,7 +792,7 @@ The meanings of
 understood in the context of Debian are discussed below:
 .TP
 .BR --deliberately-not-fast-forward
-Declare that you are deliberately rewinding history.
+Declare that you are deliberately rewriting history.
 This could be because your branch is not fast forward from the
 dgit server history,
 or not fast forward from a locally-synthesised dsc import.
@@ -824,7 +824,7 @@ never-accepted) versions in the git history of your current push, were
 rejected by ftpmaster for copyright or redistributability reasons.
 .TP
 .BR --deliberately-fresh-repo
-Declare that you are deliberately rewinding history and want to
+Declare that you are deliberately rewriting history and want to
 throw away the existing repo.  Not relevant when pushing to Debian,
 as the Debian server will do this automatically when necessary.
 .TP
index d1b4507fab135f63d4dd3ea694c40f1016715c16..bc1fdd646d6dbf3ccee1334db593f5efbb7d8301 100644 (file)
@@ -129,7 +129,8 @@ You should consider using B<prepush> or B<conclude> instead.
 =item git-debrebase scrap
 
 Throws away all the work since the branch was last stitched.
-This is done by rewinding you to ffq-prev.
+This is done by resetting you to ffq-prev
+and discarding all working tree changes.
 
 If you are in the middle of a git-rebase, will abort that too.
 
index f94315af571603c81f260fa523edf51b7afad1cd..bbf1aa215a34e054b5b4532254865365c7f6e3b4 100755 (executable)
@@ -784,7 +784,7 @@ sub checktagnoreplay () {
     #     current head for the suite (there must be at least one).
     #
     #     This prevents any tag implying a NOFFCHECK push being
-    #     replayed to rewind from a different head.
+    #     replayed to overwrite a different head.
     #
     #     The possibility of an earlier ff-only push being replayed is
     #     eliminated as follows: the tag from such a push would still