| Message ID | 20211004190050.921109-4-aclopte@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d2a534c515e5a0e0e38f077edf28b0eb4c1f011f |
| Headers | show |
| Series | [v2,1/4] Documentation/git-status: remove impossible porcelain status DR and DC | expand |
On 05/10/21 02.00, Johannes Altmanninger wrote: > @@ -211,7 +211,7 @@ show tracked paths: > * 'A' = added > * 'D' = deleted > * 'R' = renamed > -* 'C' = copied > +* 'C' = copied (if config option status.renames is set to "copies") > * 'U' = updated but unmerged > > .... > The config name and value can be formatted to monospace ("`status.renames`" and "`copies`" respectively).
On Tue, Oct 05, 2021 at 04:48:00PM +0700, Bagas Sanjaya wrote: > On 05/10/21 02.00, Johannes Altmanninger wrote: > > -* 'C' = copied > > +* 'C' = copied (if config option status.renames is set to "copies") > > The config name and value can be formatted to monospace ("`status.renames`" > and "`copies`" respectively). I wasn't sure whether to add backticks to status.renames because we are already inconsistent in this file (search for "config option"). Anyway I agree that backticks look better here (makes it bold in the man page). Maybe we should automate this? We can write a test that makes sure that we always use backticks around config keys, at least for new changes. --- I didn't add backticks to "copies" to be consistent with this part before the context Ignore changes to submodules when looking for changes. <when> can be either "none", "untracked", "dirty" or "all", which is the default.
On 06/10/21 02.42, Johannes Altmanninger wrote: > I wasn't sure whether to add backticks to status.renames because we are > already inconsistent in this file (search for "config option"). > Anyway I agree that backticks look better here (makes it bold in the man page). > > Maybe we should automate this? We can write a test that makes sure that we > always use backticks around config keys, at least for new changes. > > --- > > I didn't add backticks to "copies" to be consistent with this part before the context > > Ignore changes to submodules when looking for changes. <when> can be > either "none", "untracked", "dirty" or "all", which is the default. > I think for consistency, we can go with automated style changes that use backticks to monospace: - file name and paths - daemons/services - configuration names and values - file content (use ```...``` block unless inline) - command-line - keyboard keys (dunno?) - any other inline text that needs to be written exactly I have seen many times articles that say `Run "foo bar" (no quotes)` when they mean `Run `foo bar``. For the exception you mentioned above it can be monospaced as part of automated change above.
On Tue, Oct 5, 2021 at 10:05 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote: > > On 06/10/21 02.42, Johannes Altmanninger wrote: > > I wasn't sure whether to add backticks to status.renames because we are > > already inconsistent in this file (search for "config option"). > > Anyway I agree that backticks look better here (makes it bold in the man page). > > > > Maybe we should automate this? We can write a test that makes sure that we > > always use backticks around config keys, at least for new changes. > > > > --- > > > > I didn't add backticks to "copies" to be consistent with this part before the context > > > > Ignore changes to submodules when looking for changes. <when> can be > > either "none", "untracked", "dirty" or "all", which is the default. > > > > I think for consistency, we can go with automated style changes that use > backticks to monospace: > - file name and paths > - daemons/services > - configuration names and values > - file content (use ```...``` block unless inline) > - command-line > - keyboard keys (dunno?) > - any other inline text that needs to be written exactly > > I have seen many times articles that say `Run "foo bar" (no quotes)` > when they mean `Run `foo bar``. > > For the exception you mentioned above it can be monospaced as part of > automated change above. Doing some cleanup passes on the documentation files would probably be a good thing, but it'd probably belong in a different series. Better to keep this one focused on the fixes being proposed.
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index 255dc6af9b..8f959afa0f 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -211,7 +211,7 @@ show tracked paths: * 'A' = added * 'D' = deleted * 'R' = renamed -* 'C' = copied +* 'C' = copied (if config option status.renames is set to "copies") * 'U' = updated but unmerged ....
The man page documents that git-status can find copies, but does not mention how. Whereas git-diff has command line options -C, there is no such option for git-status - it will only detect copies when the "status.renames" config option is "copies" or "copy". Document that in git-status.txt because this has confused me and others[1]. [1]: https://www.reddit.com/r/git/comments/ppc2l9/how_to_get_a_file_with_copied_status/ Signed-off-by: Johannes Altmanninger <aclopte@gmail.com> --- Documentation/git-status.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)