Fix: lightweight tags can be pushed too

[git-wiki.git] / pep-git.txt

diff --git a/pep-git.txt b/pep-git.txt
index 15ca892eb375934a28d722172c334dcf889f398e..8ef719d2ba83a54cb7fe2b72e3731463f87ece50 100644 (file)
--- a/pep-git.txt
+++ b/pep-git.txt
@@ -199,9 +199,9 @@ and
     $ git fetch $REMOTE $BRANCH:$BRANCH
 
 The first command fetches commits from the named $BRANCH in the
     $ git fetch $REMOTE $BRANCH:$BRANCH
 
 The first command fetches commits from the named $BRANCH in the

-$REMOTE repository that are not in your repository and leaves the id
-(the hash) of the head commit in file .git/FETCH_HEAD and updates
-remote-tracking branch.
+$REMOTE repository that are not in your repository, updates
+remote-tracking branch and leaves the id (the hash) of the head commit
+in file .git/FETCH_HEAD.

 
 The second command fetches commits from the named $BRANCH in the
 $REMOTE repository that are not in your repository and updates both
 
 The second command fetches commits from the named $BRANCH in the
 $REMOTE repository that are not in your repository and updates both


@@ -326,6 +326,11 @@ from it) you do that in two steps using two repositories: you push
 from the workstation to a bare repo on the remote host, ssh to the
 remote host and pull from the bare repo to a non-bare deployment repo.
 
 from the workstation to a bare repo on the remote host, ssh to the
 remote host and pull from the bare repo to a non-bare deployment repo.
 

+That changed in git 2.3, but see `the blog post
+<https://github.com/blog/1957-git-2-3-has-been-released#push-to-deploy>`_
+for caveats; in 2.4 the push-to-deploy feature was `further improved
+<https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more#push-to-deploy-improvements>`_.
+

 Tags
 ''''
 
 Tags
 ''''
 


@@ -338,11 +343,11 @@ explicitly::
 
 For example::
 
 
 For example::
 

-    $ git fetch origin tag 1.4.2 tag 2.1.7
+    $ git fetch origin tag 1.4.2
+    $ git fetch origin v1:v1 tag 2.1.7

 
 Git doesn't automatically pushes tags. That allows you to have private
 
 Git doesn't automatically pushes tags. That allows you to have private

-tags (lightweight tags are also private for a repo, they cannot be
-pushed). To push tags list them explicitly::
+tags. To push tags list them explicitly::

 
     $ git push origin tag 1.4.2
     $ git push origin v1 v2 tag 2.1.7
 
     $ git push origin tag 1.4.2
     $ git push origin v1 v2 tag 2.1.7


@@ -386,9 +391,9 @@ Read `how to recover from upstream rebase
 It is in ``git help rebase``.
 
 On the other hand don't be too afraid about commit editing. You can
 It is in ``git help rebase``.
 
 On the other hand don't be too afraid about commit editing. You can

-safely edit, remove, reorder, combine and split commits that hasn't
+safely edit, remove, reorder, combine and split commits that haven't

 been pushed yet. You can even push commits to your own (backup) repo,
 been pushed yet. You can even push commits to your own (backup) repo,

-edit them later and force-push edited commits to replace what has
+edit them later and force-push edited commits to replace what have

 already been pushed. Not a problem until commits are in a public
 or shared repository.
 
 already been pushed. Not a problem until commits are in a public
 or shared repository.
 


@@ -483,10 +488,11 @@ git revert: revert a commit
 ---------------------------
 
 ``git revert`` reverts a commit or commits, that is, it creates a new
 ---------------------------
 
 ``git revert`` reverts a commit or commits, that is, it creates a new

-commit or commits that reverts the effects of the given commits. It's
-the only way to undo published commits (``git commit --amend``, ``git
-rebase`` and ``git reset`` change the branch in non-fast-forwardable
-ways so they should only be used for non-pushed commits.)
+commit or commits that revert(s) the effects of the given commits.
+It's the only way to undo published commits (``git commit --amend``,
+``git rebase`` and ``git reset`` change the branch in
+non-fast-forwardable ways so they should only be used for non-pushed
+commits.)

 
 There is a problem with reverting a merge commit. ``git revert`` can
 undo the code created by the merge commit but it cannot undo the fact
 
 There is a problem with reverting a merge commit. ``git revert`` can
 undo the code created by the merge commit but it cannot undo the fact


@@ -585,10 +591,31 @@ Git has a builtin merge strategy for what Python core developers call
     $ git merge -s ours v1  # null-merge v1 into v2
 
 
     $ git merge -s ours v1  # null-merge v1 into v2
 
 

-ReReRe
-======
+Advanced configuration
+======================

 
 

-https://git-scm.com/book/en/Git-Tools-Rerere
+Line endings
+------------
+
+Git has builtin mechanisms to handle line endings between platforms
+with different EOL styles. To allow git to do CRLF conversion assign
+``text`` attribute to files using `.gitattributes
+<https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html>`_.
+For files that have to have specific line ending assign ``eol``
+attribute. For binary files the attribute is, naturally, ``binary``.
+
+For example::
+
+    $ cat .gitattributes
+    *.py text
+    *.txt text
+    *.png binary
+    /readme.txt eol=CRLF
+
+To check what attributes git uses for files use ``git check-attr``
+command. For example::
+
+$ git check-attr -a -- \*.py

 
 
 Advanced topics
 
 
 Advanced topics


@@ -605,15 +632,10 @@ Staging area aka index is a distinguishing feature of git. See
 Wiki.
 
 
 Wiki.
 
 

-Advanced configuration
-======================
-
-Line endings
-------------
-
-Git has builtin mechanisms to handle line endings.
+ReReRe
+======

 
 

-TODO: describe crlf configuration and .gitattributes.
+https://git-scm.com/book/en/Git-Tools-Rerere

 
 
 Database maintenance
 
 
 Database maintenance