merge-recursive --renormalize
[gitweb.git] / Documentation / RelNotes-1.7.0.txt
index 2fedb6656a10dcd3d71898d622f8abd42f50b808..43e3f336150e1869bdae01823471d7ab216584a8 100644 (file)
@@ -4,7 +4,7 @@ Git v1.7.0 Release Notes
 Notes on behaviour change
 -------------------------
 
- * "git push" into a branch that is currently checked out (i.e. pointed by
+ * "git push" into a branch that is currently checked out (i.e. pointed at by
    HEAD in a repository that is not bare) is refused by default.
 
    Similarly, "git push $there :$killed" to delete the branch $killed
@@ -19,7 +19,7 @@ Notes on behaviour change
    patch series with more than two messages.  All messages will be sent
    as a reply to the first message, i.e. cover letter.
 
-   It has been possible to configure send-email to send "shallow thread"
+   It has been possible already to configure send-email to send "shallow thread"
    by setting sendemail.chainreplyto configuration variable to false.  The
    only thing this release does is to change the default when you haven't
    configured that variable.
@@ -30,7 +30,7 @@ Notes on behaviour change
  * "git diff" traditionally treated various "ignore whitespace" options
    only as a way to filter the patch output.  "git diff --exit-code -b"
    exited with non-zero status even if all changes were about changing the
-   ammount of whitespace and nothing else.  and "git diff -b" showed the
+   amount of whitespace and nothing else;  and "git diff -b" showed the
    "diff --git" header line for such a change without patch text.
 
    In this release, the "ignore whitespaces" options affect the semantics
@@ -106,7 +106,9 @@ Updates since v1.6.6
    defaults to the current branch, so "git fetch && git merge @{upstream}"
    will be equivalent to "git pull".
 
- * "git branch --set-upstream" can be used to update the (surprise!) upstream
+ * "git am --resolved" has a synonym "git am --continue".
+
+ * "git branch --set-upstream" can be used to update the (surprise!) upstream,
    i.e. where the branch is supposed to pull and merge from (or rebase onto).
 
  * "git checkout A...B" is a way to detach HEAD at the merge base between
@@ -133,7 +135,7 @@ Updates since v1.6.6
  * "git fetch --all" can now be used in place of "git remote update".
 
  * "git grep" does not rely on external grep anymore.  It can use more than
-   one threads to accelerate the operation.
+   one thread to accelerate the operation.
 
  * "git grep" learned "--quiet" option.
 
@@ -159,13 +161,13 @@ Updates since v1.6.6
  * "git rebase --onto A...B" means the history is replayed on top of the
    merge base between A and B.
 
- * "git rebase -i" learned new action "fixup", that squashes the change
+ * "git rebase -i" learned new action "fixup" that squashes the change
    but does not affect existing log message.
 
- * "git rebase -i" also learned --autosquash option, that is useful
+ * "git rebase -i" also learned --autosquash option that is useful
    together with the new "fixup" action.
 
- * "git remote" learned set-url subcommand, to update (surprise!) url
+ * "git remote" learned set-url subcommand that updates (surprise!) url
    for an existing remote nickname.
 
  * "git rerere" learned "forget path" subcommand.  Together with "git
@@ -200,6 +202,9 @@ release, unless otherwise noted.
    the branch is fully merged to its upstream branch if it is not merged
    to the current branch.  It now deletes it in such a case.
 
+ * "fiter-branch" command incorrectly said --prune-empty and --filter-commit
+   were incompatible; the latter should be read as --commit-filter.
+
  * When using "git status" or asking "git diff" to compare the work tree
    with something, they used to consider that a checked-out submodule with
    uncommitted changes is not modified; this could cause people to forget