Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> +`-U<n>`:: >> +`--unified=<n>`:: >> + Generate diffs with _<n>_ lines of context. Defaults to `diff.context` >> + or 3 if the config option is unset. Implies `--interactive/--patch`. >> + >> +`--inter-hunk-context=<n>`:: >> + Show the context between diff hunks, up to the specified _<number>_ >> + of lines, thereby fusing hunks that are close to each other. >> + Defaults to `diff.interHunkContext` or 0 if the config option >> + is unset. Implies `--interactive/--patch`. > > This documentation is repeated for each command. I think it would be > better to put this in separate file that is then included where it is > needed. That way if we need to update the documentation in the future > we only have one copy to worry about. The syntax to include a file > called diff-context-options.adoc is > > include::diff-context-options.adoc[] Excellent suggestion. I however think "-U implies -i/-p" makes no sense at all. What if the user said "git add -U6"? Do we run "git add -i -U6" or go directly to "git add -p -U6"? I think it is better to encourage the user to be more explicit to require them to say "git revert -U6 -p" or "git add -U6 -i". If -U<n> is given and there is no "-i" (for "add" only) or "-p" (for everything), just error out *until* other modes of these commands find a good use of context width information, at which point we can use the context length information to drive these commands in their non-"patch" mode. Even if we cannot think of a way to use the diff output (and with configurable context length) in modes that are not "--patch" for these commands RIGHT NOW, that does not mean -U<n> would never become useful in these modes for the commands. Let's not close the door prematurely from our future developers by making -U<n> imply anything, and make it an error to use -U<N> without -p/-i for now.
