git/Documentation/git-format-patch.txt, branch gitk-resize-error

doc: git-format-patch: describe the option --always

2021-12-16T01:04:15Z

This commit has described how to use '--always' option in the command 'git-format-patch' to include patches for commits that emit no changes. Signed-off-by: 徐沛文 (Aleen) Signed-off-by: Junio C Hamano

format-patch (doc): clarify --base=auto

2021-10-23T21:33:20Z

What --base=auto tells format-patch is to compute the base commit itself, using the tracking information. It does not make anything track anything. Tighten the phrasing so that it won't be copied and pasted to other places. Signed-off-by: Junio C Hamano

Merge branch 'jk/doc-format-patch-skips-merges'

2021-05-11T06:27:23Z

Document that "format-patch" skips merges. * jk/doc-format-patch-skips-merges: docs/format-patch: mention handling of merges

docs/format-patch: mention handling of merges

2021-05-03T05:32:39Z

Format-patch doesn't have a way to format merges in a way that can be applied by git-am (or any other tool), and so it just omits them. However, this may be a surprising implication for users who are not well versed in how the tool works. Let's add a note to the documentation making this more clear. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'zh/format-patch-fractional-reroll-count'

2021-04-02T21:43:14Z

"git format-patch -v" learned to allow a reroll count that is not an integer. * zh/format-patch-fractional-reroll-count: format-patch: allow a non-integral version numbers

format-patch: give an overview of what a "patch" message is

2021-03-24T19:14:23Z

The text says something called a "patch" is prepared one for each commit, it is suitable for e-mail submission, and "am" is the command to use it, but does not say what the "patch" really is. The description in the page also refers to the "three-dash" line, but it is unclear what it is, unless the reader is given a more detailed overview of what the "patch" is. Add a brief paragraph to give an overview of what the output looks like. Signed-off-by: Junio C Hamano

format-patch: allow a non-integral version numbers

2021-03-23T19:49:47Z

The `-v` option of `format-patch` can give nothing but an integral iteration number to patches in a series. Some people, however, prefer to mark a new iteration with only a small fixup with a non integral iteration number (e.g. an "oops, that was wrong" fix-up patch for v4 iteration may be labeled as "v4.1"). Allow `format-patch` to take such a non-integral iteration number. `` can be any string, such as '3.1' or '4rev2'. In the case where it is a non-integral value, the "Range-diff" and "Interdiff" headers will not include the previous version. Signed-off-by: ZheNing Hu Signed-off-by: Junio C Hamano

Merge branch 'jc/format-patch-name-max'

2020-11-21T23:14:38Z

The maximum length of output filenames "git format-patch" creates has become configurable (used to be capped at 64). * jc/format-patch-name-max: format-patch: make output filename configurable

format-patch: make output filename configurable

2020-11-10T01:44:41Z

For the past 15 years, we've used the hardcoded 64 as the length limit of the filename of the output from the "git format-patch" command. Since the value is shorter than the 80-column terminal, it could grow without line wrapping a bit. At the same time, since the value is longer than half of the 80-column terminal, we could fit two or more of them in "ls" output on such a terminal if we allowed to lower it. Introduce a new command line option --filename-max-length= and a new configuration variable format.filenameMaxLength to override the hardcoded default. While we are at it, remove a check that the name of output directory does not exceed PATH_MAX---this check is pointless in that by the time control reaches the function, the caller would already have done an equivalent of "mkdir -p", so if the system does not like an overly long directory name, the control wouldn't have reached here, and otherwise, we know that the system allowed the output directory to exist. In the worst case, we will get an error when we try to open the output file and handle the error correctly anyway. Signed-off-by: Junio C Hamano

Documentation: stylistically normalize references to Signed-off-by:

2020-10-20T18:57:40Z

Ted reported an old typo in the git-commit.txt and merge-options.txt. Namely, the phrase "Signed-off-by line" was used without either a definite nor indefinite article. Upon examination, it seems that the documentation (including items in Documentation/, but also option help strings) have been quite inconsistent on usage when referring to `Signed-off-by`. First, very few places used a definite or indefinite article with the phrase "Signed-off-by line", but that was the initial typo that led to this investigation. So, normalize using either an indefinite or definite article consistently. The original phrasing, in Commit 3f971fc425b (Documentation updates, 2005-08-14), is "Add Signed-off-by line". Commit 6f855371a53 (Add --signoff, --check, and long option-names. 2005-12-09) switched to using "Add `Signed-off-by:` line", but didn't normalize the former commit to match. Later commits seem to have cut and pasted from one or the other, which is likely how the usage became so inconsistent. Junio stated on the git mailing list in a preference to leave off the colon. Thus, prefer `Signed-off-by` (with backticks) for the documentation files and Signed-off-by (without backticks) for option help strings. Additionally, Junio argued that "trailer" is now the standard term to refer to `Signed-off-by`, saying that "becomes plenty clear that we are not talking about any random line in the log message". As such, prefer "trailer" over "line" anywhere the former word fits. However, leave alone those few places in documentation that use Signed-off-by to refer to the process (rather than the specific trailer), or in places where mail headers are generally discussed in comparison with Signed-off-by. Reported-by: "Theodore Y. Ts'o" Signed-off-by: Bradley M. Kuhn Acked-by: Taylor Blau Signed-off-by: Junio C Hamano