chiark / gitweb /
git- prefixes: Change `git-foo' to `git foo' in docs and comments
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 16 Oct 2016 11:51:08 +0000 (12:51 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 16 Oct 2016 12:11:13 +0000 (13:11 +0100)
No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
README.dsc-import
dgit

index 4bcf7fcc50c24513856fd9eb3383e68577fbf8f7..1ec53b037aab4804b94f6767a6fddb7f07cc3777 100644 (file)
@@ -17,7 +17,7 @@ interface could be designed, which is doubtful):
   Dpkg::Compression to get at the tarball.
 
   Each input tarball unpack will be done separately, and will be
   Dpkg::Compression to get at the tarball.
 
   Each input tarball unpack will be done separately, and will be
-  followed by git-add and git-write tree, to obtain a git tree object
+  followed by git add and git write-tree, to obtain a git tree object
   corresponding to the tarball contents.
 
   That tree object will be made into a commit object with no parents.
   corresponding to the tarball contents.
 
   That tree object will be made into a commit object with no parents.
@@ -80,7 +80,7 @@ This has the following properties:
   commit.  So eg `git blame' will show synthetic commits corresponding
   to the correct parts of the input source package.
 
   commit.  So eg `git blame' will show synthetic commits corresponding
   to the correct parts of the input source package.
 
-* It is possible to `git-cherry-pick' etc. commits representing `3.0
+* It is possible to `git cherry-pick' etc. commits representing `3.0
   (quilt)' patches.  It is even possible fish out the patch stack as
   git branch and rebase it elsewhere etc., since the patch stack is
   represented as a contiguous series of commits which make only the
   (quilt)' patches.  It is even possible fish out the patch stack as
   git branch and rebase it elsewhere etc., since the patch stack is
   represented as a contiguous series of commits which make only the
diff --git a/dgit b/dgit
index deb77e061e6018d030dee5d1c74799cbf50addca..04e61b82f6ae92de249fc599f1604111dcb55801 100755 (executable)
--- a/dgit
+++ b/dgit
@@ -2051,7 +2051,7 @@ sub git_fetch_us () {
     push @specs, qw(heads/*) if deliberately_not_fast_forward;
 
     # This is rather miserable:
     push @specs, qw(heads/*) if deliberately_not_fast_forward;
 
     # This is rather miserable:
-    # When git-fetch --prune is passed a fetchspec ending with a *,
+    # When git fetch --prune is passed a fetchspec ending with a *,
     # it does a plausible thing.  If there is no * then:
     # - it matches subpaths too, even if the supplied refspec
     #   starts refs, and behaves completely madly if the source
     # it does a plausible thing.  If there is no * then:
     # - it matches subpaths too, even if the supplied refspec
     #   starts refs, and behaves completely madly if the source
@@ -2061,15 +2061,15 @@ sub git_fetch_us () {
     # We want to fetch a fixed ref, and we don't know in advance
     # if it exists, so this is not suitable.
     #
     # We want to fetch a fixed ref, and we don't know in advance
     # if it exists, so this is not suitable.
     #
-    # Our workaround is to use git-ls-remote.  git-ls-remote has its
+    # Our workaround is to use git ls-remote.  git ls-remote has its
     # own qairks.  Notably, it has the absurd multi-tail-matching
     # own qairks.  Notably, it has the absurd multi-tail-matching
-    # behaviour: git-ls-remote R refs/foo can report refs/foo AND
+    # behaviour: git ls-remote R refs/foo can report refs/foo AND
     # refs/refs/foo etc.
     #
     # Also, we want an idempotent snapshot, but we have to make two
     # refs/refs/foo etc.
     #
     # Also, we want an idempotent snapshot, but we have to make two
-    # calls to the remote: one to git-ls-remote and to git-fetch.  The
-    # solution is use git-ls-remote to obtain a target state, and
-    # git-fetch to try to generate it.  If we don't manage to generate
+    # calls to the remote: one to git ls-remote and to git fetch.  The
+    # solution is use git ls-remote to obtain a target state, and
+    # git fetch to try to generate it.  If we don't manage to generate
     # the target state, we try again.
 
     my $specre = join '|', map {
     # the target state, we try again.
 
     my $specre = join '|', map {
@@ -4450,10 +4450,10 @@ sub quilt_fixup_multipatch ($$$) {
     #     2. Copy .pc from the fake's extraction, if necessary
     #     3. Run dpkg-source --commit
     #     4. If the result has changes to debian/, then
     #     2. Copy .pc from the fake's extraction, if necessary
     #     3. Run dpkg-source --commit
     #     4. If the result has changes to debian/, then
-    #          - git-add them them
-    #          - git-add .pc if we had a .pc in-tree
-    #          - git-commit
-    #     5. If we had a .pc in-tree, delete it, and git-commit
+    #          - git add them them
+    #          - git add .pc if we had a .pc in-tree
+    #          - git commit
+    #     5. If we had a .pc in-tree, delete it, and git commit
     #     6. Back in the main tree, fast forward to the new HEAD
 
     # Another situation we may have to cope with is gbp-style
     #     6. Back in the main tree, fast forward to the new HEAD
 
     # Another situation we may have to cope with is gbp-style
@@ -4462,7 +4462,7 @@ sub quilt_fixup_multipatch ($$$) {
     # We would want to detect these, so we know to escape into
     # quilt_fixup_gbp.  However, this is in general not possible.
     # Consider a package with a one patch which the dgit user reverts
     # We would want to detect these, so we know to escape into
     # quilt_fixup_gbp.  However, this is in general not possible.
     # Consider a package with a one patch which the dgit user reverts
-    # (with git-revert or the moral equivalent).
+    # (with git revert or the moral equivalent).
     #
     # That is indistinguishable in contents from a patches-unapplied
     # tree.  And looking at the history to distinguish them is not
     #
     # That is indistinguishable in contents from a patches-unapplied
     # tree.  And looking at the history to distinguish them is not