Push-to-deploy was implemented in 2.3 and improved in 2.4

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

diff --git a/pep-git.txt b/pep-git.txt
index 93407034b8dcdebefa888e4e1d578c20c88e848a..51701c9935fcb673cade2b5a89fc8ecfa0548fd4 100644 (file)
--- a/pep-git.txt
+++ b/pep-git.txt
@@ -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.
 
+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
 ''''
 
@@ -498,24 +503,23 @@ One thing that cannot be undone
 
 Whatever you undo, there is one thing that cannot be undone -
 overwritten uncommitted changes. Uncommitted changes don't belong to
-git so git cannot help with them - no way.
+git so git cannot help preserving them.
 
 Most of the time git warns you when you're going to execute a command
 that overwrites uncommitted changes. Git warns you when you try to
 switch branches with ``git checkout``. It warns you when you're going
-to rebase with non-clean working tree. It refuses to pull commits over
-non-committed files.
+to rebase with non-clean working tree. It refuses to pull new commits
+over non-committed files.
 
-But there are commands that designed exactly for that - overwriting
-files in the working tree. With commands like ``git checkout $PATHs``
-or ``git reset --hard`` git silently overwrites files including your
-uncommitted changes.
+But there are commands that do exactly that - overwrite files in the
+working tree. Commands like ``git checkout $PATHs`` or ``git reset
+--hard`` silently overwrite files including your uncommitted changes.
 
 With that in mind you can understand the stance "commit early, commit
 often". Commit as often as possible. Commit on every save in your
 editor or IDE. You can edit your commits before pushing - change,
-reorder, combine. But save your changes in git database, either in
-commits or at least in stashes.
+reorder, combine, remove. But save your changes in git database,
+either commit changes or at least stash them with ``git stash``.
 
 
 Merge or rebase?
@@ -586,10 +590,15 @@ Git has a builtin merge strategy for what Python core developers call
     $ 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.
+
+TODO: describe crlf configuration and .gitattributes.
 
 
 Advanced topics
@@ -606,15 +615,10 @@ Staging area aka index is a distinguishing feature of git. See
 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