git/Documentation/git-commit.txt, branch v2.26.3

doc: provide guidance on user.name format

2020-01-22T20:27:08Z

It's a frequent misconception that the user.name variable controls authentication in some way, and as a result, beginning users frequently attempt to change it when they're having authentication troubles. Document that the convention is that this variable represents some form of a human's personal name, although that is not required. In addition, address concerns about whether Unicode is supported. Use the term "personal name" as this is likely to draw the intended contrast, be applicable across cultures which may have different naming conventions, and be easily understandable to people who do not speak English as their first language. Indicate that "some form" is conventionally used, as people may use a nickname or preferred name instead of a full legal name. Point users who may be confused about authentication to an appropriate configuration option instead. Provide a shortened form of this information in the configuration option description. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

docs: expand on possible and recommended user config options

2020-01-22T20:27:08Z

In the section on setting author and committer information, we omit the author.* and committer.* variables, so mention them for completeness. In addition, guide users to the typical case: simply setting user.name and user.email, which are recommended if one does not need complex configuration. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

doc: move author and committer information to git-commit(1)

2020-01-22T20:27:08Z

While at one time it made perfect sense to store information about configuring author and committer information in the documentation for git commit-tree, in modern Git that operation is seldom used. Most users will use git commit and expect to find comprehensive documentation about its use in the manual page for that command. Considering that there is significant confusion about how one is to use the user.name and user.email variables, let's put as much documentation as possible into an obvious place where users will be more likely to find it. In addition, expand the environment variables section to describe their use more fully. Even though we now describe all of the options there and in the configuration settings documentation, preserve the existing text in git-commit.txt so that people can easily reason about the ordering of the various options they can use. Explain the use of the author.* and committer.* options as well. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

commit: support the --pathspec-from-file option

2019-11-20T04:01:53Z

Decisions taken for simplicity: 1) For now, `--pathspec-from-file` is declared incompatible with `--interactive/--patch`, even when is not `stdin`. Such use case it not really expected. Also, it would require changes to `interactive_add()`. 2) It is not allowed to pass pathspec in both args and file. Signed-off-by: Alexandr Miloslavskiy Signed-off-by: Junio C Hamano

doc: commit: synchronize description

2019-11-20T04:01:53Z

`git add` shows an example of good writing, follow it. This also better disambiguates ... header. Signed-off-by: Alexandr Miloslavskiy Signed-off-by: Junio C Hamano

Documentation: wrap blocks with "--"

2019-09-09T18:05:51Z

The documentation for each of these options contains a list. After the list, AsciiDoc interprets the continuation as a continuation of the *list*, not as a continution of the larger block. As a result, we get too much indentation. Wrap the entire blocks in "--" to fix this. With Asciidoctor, this commit is a no-op, and the two programs now render these identically. These two files share the same problem and indeed, they both document `--untracked-files` in quite similar ways. I haven't checked to what extent that is intentional or warranted, and to what extent they have simply drifted apart. I consider such an investigation and possible cleanup as out of scope for this commit and this patch series. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

doc: promote "git restore"

2019-05-07T04:04:48Z

The new command "git restore" (together with "git switch") are added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguous context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands. One nice thing about git-restore is the ability to restore "everything", so it can be used in "git status" advice instead of both "git checkout" and "git reset". The three commands suggested by "git status" are add, rm and restore. "git checkout" is also removed from "git help" (i.e. it's no longer considered a commonly used command) Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

git-commit.txt: better description what it does

2019-02-04T18:00:01Z

The description of git-commit jumps right into the commit content, which is important, but it fails to mention how the commit is "added" to the repository. Update the first paragraph saying a bit more about branch update to fill this gap. While at there, add a couple linkgit references when the command is first mentioned. Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

commit: add support for --fixup -m""

2017-12-22T21:10:24Z

Add support for supplying the -m option with --fixup. Doing so has errored out ever since --fixup was introduced. Before this, the only way to amend the fixup message while committing was to use --edit and amend it in the editor. The use-case for this feature is one of: * Leaving a quick note to self when creating a --fixup commit when it's not self-evident why the commit should be squashed without a note into another one. * (Ab)using the --fixup feature to "fix up" commits that have already been pushed to a branch that doesn't allow non-fast-forwards, i.e. just noting "this should have been part of that other commit", and if the history ever got rewritten in the future the two should be combined. In such a case you might want to leave a small message, e.g. "forgot this part, which broke XYZ". With this, --fixup -m"More" -m"Details" will result in a commit message like: !fixup > More Details The reason the test being added here seems to squash "More" at the end of the subject line of the commit being fixed up is because the test code is using "%s%b" so the body immediately follows the subject, it's not a bug in this code, and other tests t7500-commit.sh do the same thing. When the --fixup option was initially added the "Option -m cannot be combined" error was expanded from -c, -C and -F to also include --fixup[1] Those options could also support combining with -m, but given what they do I can't think of a good use-case for doing that, so I have not made the more invasive change of splitting up the logic in commit.c to first act on those, and then on -m options. 1. d71b8ba7c9 ("commit: --fixup option for use with rebase --autosquash", 2010-11-02) Helped-by: Eric Sunshine Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

commit doc: document that -c, -C, -F and --fixup with -m error

2017-12-22T19:20:47Z

Document that providing any of -c, -C, -F and --fixup along with -m will result in an error. Some variant of this has been errored about explicitly since 0c091296c0 ("git-commit: log parameter updates.", 2005-08-08), but the documentation was never updated to reflect this. Wording-by: Eric Sunshine Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano