On 2020-03-15 at 23:34:34, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature