doc: 'T' status code for git status
PATCH 1/1 doc: 'T' status code for git status
From: Julien Richard <[email protected]>
Git status can return 'T' status code which stands for "typechange", fixing the documentation accordingly.
---
Document 'T' status code for git status
Git status can return 'T' status code which stands for "typechange". I can't document more the behavior but it would have helped me a lot to see that line in the documentation so I guess it can help others too.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-930%2Fjairbubbles%2FgitStatusTypeChangeCode-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-930/jairbubbles/gitStatusTypeChangeCode-v1
Pull-Request: https://github.com/git/git/pull/930
Documentation/git-status.txt | 1 + 1 file changed, 1 insertion(+)
Documentation/git-status.txt +1 -0
@@ -197,6 +197,7 @@ codes can be interpreted as follows: * 'R' = renamed * 'C' = copied * 'U' = updated but unmerged +* 'T' = type changed Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`.
base-commit: 3a0b884caba2752da0af626fb2de7d597c844e8b
Signature · 1 line
gitgitgadget
Quoted 3 lines · Julien Richard via GitGitGadget
From: Julien Richard <[email protected]>
Git status can return 'T' status code which stands for "typechange", fixing the documentation accordingly.
Thanks, this is definitely an omission in the documentation.
I wonder if we need a little more, though. The list here:
Documentation/git-status.txt codes can be interpreted as follows: · line 203
Quoted 10 lines
Documentation/git-status.txt +1
-0@@ -197,6 +197,7 @@ codes can be interpreted as follows: * 'R' = renamed * 'C' = copied * 'U' = updated but unmerged +* 'T' = type changed Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`.
is followed by a table showing the meaning of those entries in each slot. Should there be some "T" entries there, too?
I think it could basically show up anywhere that "M" could.
Quoted 3 lines
Git status can return 'T' status code which stands for "typechange". I can't document more the behavior but it would have helped me a lot to see that line in the documentation so I guess it can help others too.
It is correctly documented in the diff manpage. There we define it as "change in the type of the file". I'm not sure if that's really making anything clearer than "type changed". ;)
Perhaps "type changed (e.g., a symbolic link becoming a file)" would be more descriptive, but I'm not sure it's necessary. (And if so, it probably would be better placed in the diff documentation).
-Peff
Quoted 1 line
is followed by a table showing the meaning of those entries in each slot. Should there be some "T" entries there, too?
About the table, I wasn't sure how to fill it so I felt it was safer not to touch it 😉
Quoted 1 line
Perhaps "type changed (e.g., a symbolic link becoming a file)" would be more descriptive
In fact I'm not sure how get the typechange, I always see the symbolic link example but in my case I have a 100% repro on a repository but ZI have no clue why its does so. The file is just modified but appears as a type change :-S
Could it be a bug?
About the changes you mentioned should I make the adjustements myself?
Cheers,
Julien
-----Message d'origine-----
De : Jeff King <[email protected]>
Envoyé : mercredi 9 décembre 2020 18:37
À : Julien Richard via GitGitGadget <[email protected]>
Cc : [email protected]; Julien Richard <[email protected]>; Julien Richard <[email protected]> Objet : Re: [PATCH] doc: 'T' status code for git status
Quoted 3 lines · Julien Richard via GitGitGadget
From: Julien Richard <[email protected]>
Git status can return 'T' status code which stands for "typechange", fixing the documentation accordingly.
Thanks, this is definitely an omission in the documentation.
I wonder if we need a little more, though. The list here:
Quoted 10 lines
Documentation/git-status.txt +1
-0@@ -197,6 +197,7 @@ codes can be interpreted as follows: * 'R' = renamed * 'C' = copied * 'U' = updated but unmerged +* 'T' = type changed Ignored files are not listed, unless `--ignored` option is in effect,in which case
XYare!!.
is followed by a table showing the meaning of those entries in each slot. Should there be some "T" entries there, too?
I think it could basically show up anywhere that "M" could.
Quoted 3 lines
Git status can return 'T' status code which stands for "typechange". I can't document more the behavior but it would have helped me a lot to see that line in the documentation so I guess it can help others too.
It is correctly documented in the diff manpage. There we define it as "change in the type of the file". I'm not sure if that's really making anything clearer than "type changed". ;)
Perhaps "type changed (e.g., a symbolic link becoming a file)" would be more descriptive, but I'm not sure it's necessary. (And if so, it probably would be better placed in the diff documentation).
-Peff
Quoted 8 lines · Julien Richard
Quoted 1 line
Perhaps "type changed (e.g., a symbolic link becoming a file)" would be more descriptive
In fact I'm not sure how get the typechange, I always see the symbolic link example but in my case I have a 100% repro on a repository but ZI have no clue why its does so.
The file is just modified but appears as a type change :-SCould it be a bug?
Possibly. If you have a reproduction recipe, share it and we can comment further.
Quoted 1 line
About the changes you mentioned should I make the adjustements myself?
Yes, usually you'd squash in any changes you want to make using "commit --amend" (or "rebase -i", but you only have one patch in the series), and then you can resubmit via GitGitGadget.
-Peff
PATCH v2 1/1 doc: 'T' status code for git status
In reply to Julien Richard via GitGitGadgetFrom: Julien Richard <[email protected]>
Git status can return 'T' status code which stands for "typechange", fixing the documentation accordingly.
---
Document 'T' status code for git status
Git status can return 'T' status code which stands for "typechange". I can't document more the behavior but it would have helped me a lot to see that line in the documentation so I guess it can help others too.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-930%2Fjairbubbles%2FgitStatusTypeChangeCode-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-930/jairbubbles/gitStatusTypeChangeCode-v2
Pull-Request: https://github.com/git/git/pull/930
Range-diff vs v1:
1: ee106c427a0 ! 1: 8511a2d4f10 doc: 'T' status code for git status
@@ Documentation/git-status.txt: codes can be interpreted as follows:
* 'R' = renamed
* 'C' = copied
* 'U' = updated but unmerged
-+* 'T' = type changed
++* 'T' = type changed (e.g. a symbolic link becoming a file)
Ignored files are not listed, unless --ignored option is in effect, in which case XY are !!.
Documentation/git-status.txt | 1 + 1 file changed, 1 insertion(+)
Documentation/git-status.txt +1 -0
@@ -197,6 +197,7 @@ codes can be interpreted as follows: * 'R' = renamed * 'C' = copied * 'U' = updated but unmerged +* 'T' = type changed (e.g. a symbolic link becoming a file) Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`.
base-commit: 3a0b884caba2752da0af626fb2de7d597c844e8b
Signature · 1 line
gitgitgadget
Quoted 10 lines · Jeff King
I wonder if we need a little more, though. The list here:
Quoted 8 lines
Documentation/git-status.txt +1
-0@@ -197,6 +197,7 @@ codes can be interpreted as follows: * 'R' = renamed * 'C' = copied * 'U' = updated but unmerged +* 'T' = type changed
Quoted 7 lines
Documentation/git-status.txt codes can be interpreted as follows: · line 203
Quoted 2 lines
Documentation/git-status.txt +0
-0Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`.is followed by a table showing the meaning of those entries in each slot. Should there be some "T" entries there, too?
I think it could basically show up anywhere that "M" could.
Meaning something like the patch attached at the end, perhaps?
Quoted 7 lines
It is correctly documented in the diff manpage. There we define it as "change in the type of the file". I'm not sure if that's really making anything clearer than "type changed". ;)
Perhaps "type changed (e.g., a symbolic link becoming a file)" would be more descriptive, but I'm not sure it's necessary. (And if so, it probably would be better placed in the diff documentation).
Sitting next to existing copied, renamed, and updated-but-unmerged, the extra explanation in parentheses looks a bit out of place. It does make sense to have it described in the diff documentation, but I think it already is covered adequately over there.
Another thing I noticed while looking at the context is that "updated but" is misleading. You might be in the middle of a merge, and the path may have been modified in their history as well as somewhere in your history, but the change in your history may be far in the past that you do not even care or remember. As far as you are concerned, you didn't update it (e.g. relative to HEAD) at all. It simply is "unmerged"---if you take a look at the conflicted contents, saved it and then perhaps "git add" it, you may now be able to call the path "updated", but at that point it is no longer "unmerged".
Thanks.
A few things about the attached.
- it drops "updated but" from the explanation of 'U' in the list.
- after that, everything in the list becomes a single-word, so instead of "type changed", it invents a verb "type-change" and uses its pp. form when adding an entry for 'T'.
- it updates the table to add 'T' next to 'M'.
- "work tree changed since index" in the table was awkward; it rephrases it to "modified in work tree relative to index", because (1) these entries are not talking about the working tree as a whole; it is one path in the working tree changing its type. and (2) using "changed" and "updated" for the same 'M' in different context was unnecessarily confusing. Instead, it uses 'modified', which appears in the list before the table.
- The "not updated" line was using a leading "\t"ab, and that is why the preimage appears unaligned; the patch updates the line to use 8 spaces (i.e. ' ' for X and 7 spaces to align).
Documentation/git-status.txt | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
Documentation/git-status.txt +12 -9
@@ -196,7 +196,8 @@ codes can be interpreted as follows: * 'D' = deleted * 'R' = renamed * 'C' = copied -* 'U' = updated but unmerged +* 'U' = unmerged +* 'T' = type-changed Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`.
@@ -204,15 +205,17 @@ in which case `XY` are `!!`. .... X Y Meaning ------------------------------------------------- - [AMD] not updated -M [ MD] updated in index -A [ MD] added to index + [AMTD] not changed +M [ MTD] modified in index +T [ MTD] type-changed in index +A [ MTD] added to index D deleted from index -R [ MD] renamed in index -C [ MD] copied in index -[MARC] index and work tree matches -[ MARC] M work tree changed since index -[ MARC] D deleted in work tree +R [ MTD] renamed in index +C [ MTD] copied in index +[MTARC] index and work tree matches +[ MTARC] M modified in work tree relative to index +[ MTARC] T type-changed in work tree relative to index +[ MTARC] D deleted in work tree [ D] R renamed in work tree [ D] C copied in work tree -------------------------------------------------
I investigated a bit more my case and it is indeed a file which is modified and is now a symlink. If it's only the main case I think it would be nice to add it to the documentation as the 'typechange' can be quite mysterious otherwise (internet is not much of help on the subject appart from https://code-examples.net/en/q/849dff ).
I don't find the table very explicit, for instance I don't understand the []. Is it all the possible statuses in the index / worktree for a given status? With the T added the table becomes even more complex. As the T status seems like a corner case, mentioning it in the doc briefly would be sufficient, at least for my use case.
Thx,
Julien
-----Message d'origine-----
De : Junio C Hamano <[email protected]>
Envoyé : mercredi 9 décembre 2020 21:26
À : Jeff King <[email protected]>
Cc : Julien Richard via GitGitGadget <[email protected]>; [email protected]; Julien Richard <[email protected]>; Julien Richard <[email protected]> Objet : Re: [PATCH] doc: 'T' status code for git status
Quoted 10 lines · Jeff King
I wonder if we need a little more, though. The list here:
Quoted 8 lines
Documentation/git-status.txt +1
-0@@ -197,6 +197,7 @@ codes can be interpreted as follows: * 'R' = renamed * 'C' = copied * 'U' = updated but unmerged +* 'T' = type changed
Quoted 7 lines
Quoted 2 lines
Documentation/git-status.txt +0
-0Ignored files are not listed, unless `--ignored` option is ineffect, in which case
XYare!!.is followed by a table showing the meaning of those entries in each slot. Should there be some "T" entries there, too?
I think it could basically show up anywhere that "M" could.
Meaning something like the patch attached at the end, perhaps?
Quoted 7 lines
It is correctly documented in the diff manpage. There we define it as "change in the type of the file". I'm not sure if that's really making anything clearer than "type changed". ;)
Perhaps "type changed (e.g., a symbolic link becoming a file)" would be more descriptive, but I'm not sure it's necessary. (And if so, it probably would be better placed in the diff documentation).
Sitting next to existing copied, renamed, and updated-but-unmerged, the extra explanation in parentheses looks a bit out of place. It does make sense to have it described in the diff documentation, but I think it already is covered adequately over there.
Another thing I noticed while looking at the context is that "updated but" is misleading. You might be in the middle of a merge, and the path may have been modified in their history as well as somewhere in your history, but the change in your history may be far in the past that you do not even care or remember. As far as you are concerned, you didn't update it (e.g. relative to HEAD) at all. It simply is "unmerged"---if you take a look at the conflicted contents, saved it and then perhaps "git add" it, you may now be able to call the path "updated", but at that point it is no longer "unmerged".
Thanks.
A few things about the attached.
- it drops "updated but" from the explanation of 'U' in the list.
- after that, everything in the list becomes a single-word, so instead of "type changed", it invents a verb "type-change" and uses its pp. form when adding an entry for 'T'.
- it updates the table to add 'T' next to 'M'.
- "work tree changed since index" in the table was awkward; it rephrases it to "modified in work tree relative to index", because (1) these entries are not talking about the working tree as a whole; it is one path in the working tree changing its type. and (2) using "changed" and "updated" for the same 'M' in different context was unnecessarily confusing. Instead, it uses 'modified', which appears in the list before the table.
- The "not updated" line was using a leading "\t"ab, and that is why the preimage appears unaligned; the patch updates the line to use 8 spaces (i.e. ' ' for X and 7 spaces to align).
Documentation/git-status.txt | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
Documentation/git-status.txt +12 -9
@@ -196,7 +196,8 @@ codes can be interpreted as follows: * 'D' = deleted * 'R' = renamed * 'C' = copied -* 'U' = updated but unmerged +* 'U' = unmerged +* 'T' = type-changed Ignored files are not listed, unless `--ignored` option is in effect, in which case `XY` are `!!`.
@@ -204,15 +205,17 @@ in which case `XY` are `!!`. .... X Y Meaning ------------------------------------------------- - [AMD] not updated -M [ MD] updated in index -A [ MD] added to index + [AMTD] not changed +M [ MTD] modified in index +T [ MTD] type-changed in index +A [ MTD] added to index D deleted from index -R [ MD] renamed in index -C [ MD] copied in index -[MARC] index and work tree matches -[ MARC] M work tree changed since index -[ MARC] D deleted in work tree +R [ MTD] renamed in index +C [ MTD] copied in index +[MTARC] index and work tree matches +[ MTARC] M modified in work tree relative to index +[ MTARC] T type-changed in work tree relative to index +[ MTARC] D deleted in work tree [ D] R renamed in work tree [ D] C copied in work tree -------------------------------------------------
Quoted 3 lines · Junio C Hamano
A few things about the attached.
- it drops "updated but" from the explanation of 'U' in the list.
Seems reasonable.
Quoted 3 lines
- after that, everything in the list becomes a single-word, so instead of "type changed", it invents a verb "type-change" and uses its pp. form when adding an entry for 'T'.
Also reasonable.
Quoted 1 line
- it updates the table to add 'T' next to 'M'.
Yep, that was what I was thinking would make sense.
Quoted 7 lines
- "work tree changed since index" in the table was awkward; it rephrases it to "modified in work tree relative to index", because (1) these entries are not talking about the working tree as a whole; it is one path in the working tree changing its type. and (2) using "changed" and "updated" for the same 'M' in different context was unnecessarily confusing. Instead, it uses 'modified', which appears in the list before the table.
The first line seems funny to me now, though (diff abridged):
Documentation/git-status.txt in which case `XY` are `!!`. · line 208
Quoted 2 lines
Documentation/git-status.txt +1
-1- [AMD] not updated + [AMTD] not changed
If the file is not changed, then why are we even mentioning it? Because of course it _is_ changed in the filesystem, but the index was not updated to reflect the change. And that's what I think the original was getting at with "updated".
TBH, I find the whole table overly confusing. But then, I am completely comfortable with the notion that it is really showing two diffs, with their results collated. To me it is simpler to just discuss the two sides of the diff independently, and then you do not even really need a table at all ("M" means modified no matter which column it appears in). But I may not be a representative Git user.
-Peff
Quoted 6 lines · Jeff King
TBH, I find the whole table overly confusing. But then, I am completely comfortable with the notion that it is really showing two diffs, with their results collated. To me it is simpler to just discuss the two sides of the diff independently, and then you do not even really need a table at all ("M" means modified no matter which column it appears in). But I may not be a representative Git user.
Me neither. I think the folks who originally wanted to see the table was curious about what combination of X and Y are possible.
For example, if a path is deleted in the index, there won't be any intelligent thing we can say about the path in the working tree, so after "git rm COPYING" we'd see "D COPYING", not "DD COPYING", and after "git rm --cached COPYING && date >COPYING", we'd still see "D COPYING", not "DM COPYING".
It is unclear how such knowledge would be useful to the readers, so I won't shed tears if we got rid of the table; the bits saved might be better used to enhance the description in the list of mnemonics.
Thanks.