Re: [PATCH 1/1] docs: add a FAQ
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Mar 16, 2020, 00:13 UTC
- Message-ID
- <20200316001329.GB6910@camp.crustytoothpaste.net>
- In-Reply-To
- <xmqqa74h9oqd.fsf@gitster.c.googlers.com>
On 2020-03-15 at 23:34:34, Junio C Hamano wrote:
Show 7 quoted lines
> "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).
Show 14 quoted lines
> > +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.
Show 5 quoted lines
> 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.
Show 12 quoted lines
> > +[[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