Merge commit 'v1.7.0' into jc/checkout-reflog-fix

* commit 'v1.7.0': (4188 commits)
  Git 1.7.0
  Fix typo in 1.6.6.2 release notes
  Re-fix check-ref-format documentation mark-up
  archive documentation: attributes are taken from the tree by default
  Documentation: minor fixes to RelNotes-1.7.0
  bash: support 'git am's new '--continue' option
  filter-branch: Fix error message for --prune-empty --commit-filter
  am: switch --resolved to --continue
  Update draft release notes to 1.7.0 one more time
  Git 1.6.6.2
  t8003: check exit code of command and error message separately
  check-ref-format documentation: fix enumeration mark-up
  Documentation: quote braces in {upstream} notation
  t3902: Protect against OS X normalization
  blame: prevent a segv when -L given start > EOF
  git-push: document all the status flags used in the output
  Fix parsing of imap.preformattedHTML and imap.sslverify
  git-add documentation: Fix shell quoting example
  Revert "pack-objects: fix pack generation when using pack_size_limit"
  archive: simplify archive format guessing
  ...

1 files changed, 0 insertions, 79 deletions

diff --git a/Documentation/howto/rebase-and-edit.txt b/Documentation/howto/rebase-and-edit.txt
deleted file mode 100644
index 554909fe08..0000000000
--- a/Documentation/howto/rebase-and-edit.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Date:	Sat, 13 Aug 2005 22:16:02 -0700 (PDT)
-From:	Linus Torvalds <torvalds@osdl.org>
-To:	Steve French <smfrench@austin.rr.com>
-cc:	git@vger.kernel.org
-Subject: Re: sending changesets from the middle of a git tree
-Abstract: In this article, Linus demonstrates how a broken commit
- in a sequence of commits can be removed by rewinding the head and
- reapplying selected changes.
-
-On Sat, 13 Aug 2005, Linus Torvalds wrote:
-
-> That's correct. Same things apply: you can move a patch over, and create a
-> new one with a modified comment, but basically the _old_ commit will be
-> immutable.
-
-Let me clarify.
-
-You can entirely _drop_ old branches, so commits may be immutable, but
-nothing forces you to keep them. Of course, when you drop a commit, you'll
-always end up dropping all the commits that depended on it, and if you
-actually got somebody else to pull that commit you can't drop it from
-_their_ repository, but undoing things is not impossible.
-
-For example, let's say that you've made a mess of things: you've committed
-three commits "old->a->b->c", and you notice that "a" was broken, but you
-want to save "b" and "c". What you can do is
-
-	# Create a branch "broken" that is the current code
-	# for reference
-	git branch broken
-
-	# Reset the main branch to three parents back: this
-	# effectively undoes the three top commits
-	git reset HEAD^^^
-	git checkout -f
-
-	# Check the result visually to make sure you know what's
-	# going on
-	gitk --all
-
-	# Re-apply the two top ones from "broken"
-	#
-	# First "parent of broken" (aka b):
-	git-diff-tree -p broken^ | git-apply --index
-	git commit --reedit=broken^
-
-	# Then "top of broken" (aka c):
-	git-diff-tree -p broken | git-apply --index
-	git commit --reedit=broken
-
-and you've now re-applied (and possibly edited the comments) the two
-commits b/c, and commit "a" is basically gone (it still exists in the
-"broken" branch, of course).
-
-Finally, check out the end result again:
-
-	# Look at the new commit history
-	gitk --all
-
-to see that everything looks sensible.
-
-And then, you can just remove the broken branch if you decide you really
-don't want it:
-
-	# remove 'broken' branch
-	git branch -d broken
-
-	# Prune old objects if you're really really sure
-	git prune
-
-And yeah, I'm sure there are other ways of doing this. And as usual, the
-above is totally untested, and I just wrote it down in this email, so if
-I've done something wrong, you'll have to figure it out on your own ;)
-
-			Linus
--
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html