On Sun, Feb 17, 2013 at 06:23:11PM -0800, Junio C Hamano wrote: > "W. Trevor King" writes: > > [[rewriting-one-commit]] > > Rewriting a single commit > > ------------------------- > > @@ -2552,71 +2558,81 @@ $ git commit --amend > > which will replace the old commit by a new commit incorporating your > > changes, giving you a chance to edit the old commit message first. > > > > ... A lot of lines removed here ... > > > +[[reordering-patch-series]] > > This change makes the [[rewriting-one-commit]] section say "We > already saw you can do 'commit --amend'" and nothing else. It makes > me wonder if the remaining section is worth keeping if we go this > route. I think there should be some mention of `commit --amend` in the rewriting history section. It's a pretty straightforward idea though, so there's not all that much to say about it ;). > > +Then modify, reorder, or eliminate patches as preferred before applying > > +them again with linkgit:git-am[1]: > > > > ------------------------------------------------- > > +$ git am *.patch > > ------------------------------------------------- > > It may be just me, but s/preferred/needed/, perhaps? Sure. I was just shifting the existing text. Will fix in v4. > > +The rebase will stop when `pick` has been replaced with `edit` or when > > +a command fails due to merge errors. When you are done editing and/or > > +resolving conflicts... > > I am afraid that "due to merge errors" and "resolving conflicts" do > not look corresponding to each other for a new reader. Also here we > say "when a command fails", but the explanation before this part > never says "list of commands". Oops. s/command/commit/. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy