Re: [PATCH 2/2] Documentation/git-status: document porcelain status T (typechange)
- From
Elijah Newren <newren@gmail.com>
- Date
- Oct 2, 2021, 23:29 UTC
- Message-ID
- <CABPp-BFqJi0q0844NKfU8K5HRpAJ7yP2OkyBUiFQSAw-ZjNoyw@mail.gmail.com>
- In-Reply-To
- <20211002213046.725892-2-aclopte@gmail.com>
On Sat, Oct 2, 2021 at 2:38 PM Johannes Altmanninger <aclopte@gmail.com> wrote:
Show 5 quoted lines
> > As reported in [1], T is missing from the description of porcelain > status letters in git-status(1) (whereas T is documented in > git-diff-files(1) and friends). Document T right after M (modified) > because the two are very similar.
Good; thanks for sending this in.
> A porcelain status containing C (copied) is impossible because "git > status" does not detect copies, only renames.
This is no true (since ~2018); here's an example:
$ cp -a README.md README-copy
$ echo garbage >>README.md
$ git add README-copy README.md
$ git -c status.renames=copy status --porcelain
C README.md -> README-copy
M README.mdYou can also use diff.renames instead of status.renames, since the latter defaults to the former. Note that you do need to both modify and stage README.md in the example above to see the copy status.
Show 5 quoted lines
> I was going to delete > mentions of C from git-status.txt because it keeps confusing users [2] > but a discussion from 2014 suggests that "git status" should re-learn > to detect copies, which was disabled in 2005 for (obsolete) performance > reasons [3].
That thread you refer to suggests it was turned off because copy detection meant the equivalent of find-copies-harder, and that thread also provided numbers showing find-copies-harder would still be very painful performance-wise. Perhaps the "obsolete performance reasons" was meant to imply that basic copy detection is cheaper since it does something different today than what status's copy detection did back then, but summarizing this as "obsolete performance reasons" feels misleading to me.
> [1] https://github.com/fish-shell/fish-shell/issues/8311 > [2] https://www.reddit.com/r/git/comments/ppc2l9/how_to_get_a_file_with_copied_status/ > [3] https://marc.info/?l=git&m=141755095826447&w=2
Links to lore.kernel.org would be much preferred to marc.info links; here that would be https://lore.kernel.org/git/20141202200910.GB23461@peff.net/.
The lore.kernel.org links provide an interface to easily search for other mailing list messages, and use the Message-ID in the URL which makes it easier for people to find the message in other locations, etc.
Show 38 quoted lines
> Signed-off-by: Johannes Altmanninger <aclopte@gmail.com> > --- > Documentation/git-status.txt | 17 ++++++++++------- > 1 file changed, 10 insertions(+), 7 deletions(-) > > diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt > index 83f38e3198..40f308c6a6 100644 > --- a/Documentation/git-status.txt > +++ b/Documentation/git-status.txt > @@ -207,6 +207,7 @@ show tracked paths: > > * ' ' = unmodified > * 'M' = modified > +* 'T' = file type changed (regular file, symbolic link or submodule) > * 'A' = added > * 'D' = deleted > * 'R' = renamed > @@ -217,14 +218,16 @@ show tracked paths: > X Y Meaning > ------------------------------------------------- > [AMD] not updated > -M [ MD] updated in index > -A [ MD] added to index > +M [ MTD] updated 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 work tree changed since index > +[ MTARC] T type changed in work tree since index > +[ MTARC] D deleted in work tree
Looks good up to here.
> [ D] R renamed in work tree > [ D] C copied in work tree
This wasn't something you added; it appears these two came from commit 176ea74793 ("wt-status.c: handle worktree renames", 2017-12-27). However, I don't think the 'D' part of these examples is possible. If a file is deleted in the index relative to HEAD (what the 'D' means), then comparing the index to the worktree means the file didn't even exist in the index. Thus no delete pair for that file will be passed to diffcore-rename, and without a delete pair for some file, there is nothing for the add pairs to be combined with to create a rename or copy pair. So these lines are misleading and should only have a space in the first column rather than either a space or 'D'.
That said, of course, since this wasn't caused by your patch, you are under no obligation to fix. It would go nicely with your series, though. Would you like to add another patch to your series to fix that, or would you rather that I contributed such a patch separately?
Thanks for the contribution!