On 2020-03-15 at 23:34:34, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > Note that the long lines for certain questions are required, since
> > Asciidoctor does not permit broken lines there.
> 
> I didn't see "long lines", but was puzzled by a few lines with
> ununiform indentation.

I'll fix all that.  Apparently somewhere along the line my editor got
confused and inserted two spaces (which is my typical AsciiDoc
configuration) instead of a tab (which is what I've configured for Git
files).

> > +Common Issues
> > +-------------
> > +
> > +[[last-commit-amend]]
> > +I've made a mistake in the last commit.  How do I change it?::
> > +	You can make the appropriate change to your working tree, run `git add <file>`
> > +	to stage it, and then `git commit --amend`.  Your change will be included in
> > +	the commit, and you'll be prompted to edit the commit message again; if you
> > +	don't want to edit it, you can use the `--no-edit` option to `git commit` in
> > +	addition, or just save and quit when your editor opens.
> 
> When the undesired part of the last change was "I added a junk
> file", then instead of `git add`, `git rm [--cached]` would become
> necessary.

Good point.  I'll mention `git add` or `git rm` as appropriate.

> I personally would prefer to say "if you want to use the original
> commit message verbatim" instead of "you do not want to edit", but
> it may be just me.  I just find the document to give more positive
> attitude if it avoids phrasing end-users' wishes in terms of what
> they do not want to do.

Thanks.  This is great feedback.

> > +[[undo-previous-change]]
> > +I've made a change with a bug and it's been included in the main branch.  How should I undo it?::
> > +	The usual way to deal with this is to use `git revert`.  This preserves the
> > +	history that the original change was made and was a valuable contribution, but
> > +	also introduces a new commit that undoes those changes because the original
> > +	had a problem.  The commit message of the revert indicates the commit which
> > +	was reverted and can be edited to include an explanation as to why the revert
> > +	was made.
> 
> Can we phrase "and can be edited" in a bit more opinionated way?
> The users are encouraged to describe why and that is why we open an
> editor by default for them to do so.

Yes, I agree that we want to encourage a helpful commit message here.  Will update.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204