git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Julien Richard <julien.richard@ubisoft.com>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: Julien Richard via GitGitGadget <gitgitgadget@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	Julien Richard <jairbubbles@hotmail.com>
Subject: RE: [PATCH] doc: 'T' status code for git status
Date: Wed, 9 Dec 2020 20:56:27 +0000	[thread overview]
Message-ID: <BYAPR17MB264673B29978D31681D5B3119DCC0@BYAPR17MB2646.namprd17.prod.outlook.com> (raw)
In-Reply-To: <xmqqsg8e20b8.fsf@gitster.c.googlers.com>

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 <gitster@pobox.com> 
Envoyé : mercredi 9 décembre 2020 21:26
À : Jeff King <peff@peff.net>
Cc : Julien Richard via GitGitGadget <gitgitgadget@gmail.com>; git@vger.kernel.org; Julien Richard <jairbubbles@hotmail.com>; Julien Richard <julien.richard@ubisoft.com>
Objet : Re: [PATCH] doc: 'T' status code for git status

Jeff King <peff@peff.net> writes:

> I wonder if we need a little more, though. The list here:
>
>> --- a/Documentation/git-status.txt
>> +++ b/Documentation/git-status.txt
>> @@ -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.

Meaning something like the patch attached at the end, perhaps?

> 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(-)

diff --git c/Documentation/git-status.txt w/Documentation/git-status.txt index 7731b45f07..2e4b761ecc 100644
--- c/Documentation/git-status.txt
+++ w/Documentation/git-status.txt
@@ -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
 -------------------------------------------------

  reply	other threads:[~2020-12-09 20:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  8:13 [PATCH] doc: 'T' status code for git status Julien Richard via GitGitGadget
2020-12-09 17:37 ` Jeff King
2020-12-09 18:01   ` Julien Richard
2020-12-09 18:35     ` Jeff King
2020-12-09 20:26   ` Junio C Hamano
2020-12-09 20:56     ` Julien Richard [this message]
2020-12-09 21:32     ` Jeff King
2020-12-10  0:47       ` Junio C Hamano
2020-12-09 19:12 ` [PATCH v2] " Julien Richard via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR17MB264673B29978D31681D5B3119DCC0@BYAPR17MB2646.namprd17.prod.outlook.com \
    --to=julien.richard@ubisoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=jairbubbles@hotmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).