File move with `add -N` shows as rename to same name

I just stumbled across the following oddity:

Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair.

After that commit, an i-t-a entry can appear as a new file in "git diff-files". But the diff callback function in wt-status.c does not handle this case and produces incorrect status output.

Handle this rename case. While at there make sure unhandled diff status code is reported to catch cases like this easier in the future.

The reader may notice that this patch adds a new xstrdup() but not a free(). Yes we leak memory (the same for head_path). But wt_status so far has been short lived, this leak should not matter in practice.

Noticed-by Alex Vandiver <[email protected]>

Signed-off-by Nguyễn Thái Ngọc Duy <[email protected]>

---
 t/t2203-add-intent.sh | 15 +++++++++++++++
 wt-status.c           | 24 +++++++++++++++++++-----
 wt-status.h           |  1 +
 3 files changed, 35 insertions(+), 5 deletions(-)

t/t2203-add-intent.sh +15 -0

index 1bdf38e80d..41a8874e60 100755
@@ -150,5 +150,20 @@ test_expect_success 'commit: ita entries ignored in empty commit check' '
 	)
 '
 
+test_expect_success 'rename detection finds the right names' '
+	git init rename-detection &&
+	(
+		cd rename-detection &&
+		echo contents > original-file &&
+		git add original-file &&
+		git commit -m first-commit &&
+		mv original-file new-file &&
+		git add -N new-file &&
+		git status --porcelain | grep -v actual >actual &&
+		echo " R original-file -> new-file" >expected &&
+		test_cmp expected actual
+	)
+'
+
 test_done
 

wt-status.c +19 -5

index ef26f07446..f0b5b3d46a 100644
@@ -376,6 +376,8 @@ static void wt_longstatus_print_change_data(struct wt_status *s,
 			strbuf_addch(&extra, ')');
 		}
 		status = d->worktree_status;
+		if (d->worktree_path)
+			one_name = d->worktree_path;
 		break;
 	default:
 		die("BUG: unhandled change_type %d in wt_longstatus_print_change_data",

@@ -432,7 +434,7 @@ static void wt_status_collect_changed_cb(struct diff_queue_struct *q,
 		struct wt_status_change_data *d;
 
 		p = q->queue[i];
-		it = string_list_insert(&s->change, p->one->path);
+		it = string_list_insert(&s->change, p->two->path);
 		d = it->util;
 		if (!d) {
 			d = xcalloc(1, sizeof(*d));

@@ -459,6 +461,12 @@ static void wt_status_collect_changed_cb(struct diff_queue_struct *q,
 			/* mode_worktree is zero for a delete. */
 			break;
 
+		case DIFF_STATUS_COPIED:
+		case DIFF_STATUS_RENAMED:
+			d->worktree_path = xstrdup(p->one->path);
+			d->score = p->score * 100 / MAX_SCORE;
+			/* fallthru */
+
 		case DIFF_STATUS_MODIFIED:
 		case DIFF_STATUS_TYPE_CHANGED:
 		case DIFF_STATUS_UNMERGED:

@@ -467,8 +475,8 @@ static void wt_status_collect_changed_cb(struct diff_queue_struct *q,
 			oidcpy(&d->oid_index, &p->one->oid);
 			break;
 
-		case DIFF_STATUS_UNKNOWN:
-			die("BUG: worktree status unknown???");
+		default:
+			die("BUG: unhandled worktree status '%c'", p->status);
 			break;
 		}
 

@@ -548,6 +556,10 @@ static void wt_status_collect_updated_cb(struct diff_queue_struct *q,
 			 * values in these fields.
 			 */
 			break;
+
+		default:
+			die("BUG: unhandled worktree status '%c'", p->status);
+			break;
 		}
 	}
 }

@@ -1724,8 +1736,10 @@ static void wt_shortstatus_status(struct string_list_item *it,
 	} else {
 		struct strbuf onebuf = STRBUF_INIT;
 		const char *one;
-		if (d->head_path) {
-			one = quote_path(d->head_path, s->prefix, &onebuf);
+
+		one = d->head_path ? d->head_path : d->worktree_path;
+		if (one) {
+			one = quote_path(one, s->prefix, &onebuf);
 			if (*one != '"' && strchr(one, ' ') != NULL) {
 				putchar('"');
 				strbuf_addch(&onebuf, '"');

wt-status.h +0 -0

index fe27b465e2..572a720123 100644

But I`ve noticed that "--porcelain=v2" output might still be buggy - this is what having both files staged shows:

    $ git status --porcelain=v2
    2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 R100 new-file	original-file

..., where having old/deleted file unstaged, and new/created file staged with git add -N shows this:

    $ git status --porcelain=v2
    1 .R N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 new-file

So even though unstaged value is correctly recognized as "R" (renamed), first number is "1" (instead of "2" to signal rename/copy), and both rename score and original file name are missing.

I guess an additional test for this would be good, too.

But I`ve noticed that "--porcelain=v2" output might still be buggy - this is what having both files staged shows:

    $ git status --porcelain=v2
    2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 R100 new-file	original-file

..., where having old/deleted file unstaged, and new/created file staged with git add -N shows this:

    $ git status --porcelain=v2
    1 .R N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 new-file

So even though unstaged value is correctly recognized as "R" (renamed), first number is "1" (instead of "2" to signal rename/copy), and both rename score and original file name are missing.

Not sure if this is a bug, but it seems so, as git status "Porcelain Format Version 2"[1] says the last path is "pathname in the commit at HEAD" (in case of copy/rename), which is missing here.

Quoted 12 lines · Igor Djordjevic

But I`ve noticed that "--porcelain=v2" output might still be buggy - this is what having both files staged shows:

    $ git status --porcelain=v2
    2 R. N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 R100 new-file    original-file

..., where having old/deleted file unstaged, and new/created file staged with git add -N shows this:

    $ git status --porcelain=v2
    1 .R N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 new-file

Quoted 7 lines

So even though unstaged value is correctly recognized as "R" (renamed), first number is "1" (instead of "2" to signal rename/copy), and both rename score and original file name are missing.

Not sure if this is a bug, but it seems so, as git status "Porcelain Format Version 2"[1] says the last path is "pathname in the commit at HEAD" (in case of copy/rename), which is missing here.

Yeah v2 looks problematic. The way the document is written, it's not prepared to deal with a rename pair coming from comparing the index (with intent-to-add entries) with worktree, only from comparing with HEAD. So either we could ajust v2 semantics slightly like this

Documentation/git-status.txt +4 -4

index 81cab9aefb..3da10020aa 100644
@@ -309,13 +309,13 @@ Renamed or copied entries have the following format:
                of similarity between the source and target of the
                move or copy). For example "R100" or "C75".
     <path>      The pathname.  In a renamed/copied entry, this
-               is the path in the index and in the working tree.
+               is the path in the index.
     <sep>       When the `-z` option is used, the 2 pathnames are separated
                with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
                byte separates them.
-    <origPath>  The pathname in the commit at HEAD.  This is only
-               present in a renamed/copied entry, and tells
-               where the renamed/copied contents came from.
+    <origPath>  The pathname in the commit at HEAD or in the worktree.
+               This is only present in a renamed/copied entry, and
+               tells where the renamed/copied contents came from.
     --------------------------------------------------------
 
 Unmerged entries have the following format; the first character is

The problem is, you cannot know if it's a rename from HEAD or from worktree with this updated v2 (or perhaps you could because HEAD name should be all zero?).

Quoted 3 lines

The problem is, you cannot know if it's a rename from HEAD or from worktree with this updated v2 (or perhaps you could because HEAD name should be all zero?).

I'm wrong about this. the "<XY>" code for HEAD rename would be "R." while worktree rename is ".R" so I think we're good.

Or we disable rename-from-worktree when porcelain v2 is requested (and optionally introduce v3 to support it). Jeff, any preference?

Quoted 2 lines · Duy Nguyen

Or we disable rename-from-worktree when porcelain v2 is requested (and optionally introduce v3 to support it). Jeff, any preference?

Also, does this introduce any new cases for reporting conflicts? I haven't really thought about it too much yet, but if there was a divergent rename in both branches of a merge, do we now have to handle showing possibly 4 pathnames for a file? (merge-base, branch-a, branch-b, worktree)

Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair.

After that commit, an i-t-a entry can appear as a new file in "git diff-files". But the diff callback function in wt-status.c does not handle this case and produces incorrect status output.

PS. The reader may notice that this patch adds a new xstrdup() but not a free(). Yes we leak memory (the same for head_path). But wt_status so far has been short lived, this leak should not matter in practice.

Noticed-by Alex Vandiver <[email protected]>

Helped-by Igor Djordjevic <[email protected]>

Signed-off-by Nguyễn Thái Ngọc Duy <[email protected]>

---
 t/t2203-add-intent.sh | 28 ++++++++++++++++++++
 wt-status.c           | 72 +++++++++++++++++++++++++++++++++++++++------------
 wt-status.h           |  4 +--
 3 files changed, 85 insertions(+), 19 deletions(-)

t/t2203-add-intent.sh +19 -0

index 878e73fe98..e5bfda1853 100755
@@ -162,5 +162,33 @@ test_expect_success 'commit: ita entries ignored in empty commit check' '
 	)
 '
 
+test_expect_success 'rename detection finds the right names' '
+	git init rename-detection &&
+	(
+		cd rename-detection &&
+		echo contents > first &&
+		git add first &&
+		git commit -m first &&
+		mv first third &&
+		git add -N third &&
+
+		git status | grep -v "^?" >actual.1 &&
+		test_i18ngrep "renamed: *first -> third" actual.1 &&
+
+		git status --porcelain | grep -v "^?" >actual.2 &&
+		cat >expected.2 <<-\EOF &&
+		 R first -> third
+		EOF
+		test_cmp expected.2 actual.2 &&
+

wt-status.c +2 -0

index c124d7589c..d5bdf4c2e9 100644
@@ -376,6 +376,8 @@ static void wt_longstatus_print_change_data(struct wt_status *s,
 			strbuf_addch(&extra, ')');
 		}
 		status = d->worktree_status;
+		if (d->worktree_path)
+			two_name = d->worktree_path;
 		break;
 	default:
 		die("BUG: unhandled change_type %d in wt_longstatus_print_change_data",

wt-status.c +34 -10

+			d->worktree_score = p->score * 100 / MAX_SCORE;
+			/* fallthru */
+
 		case DIFF_STATUS_MODIFIED:
 		case DIFF_STATUS_TYPE_CHANGED:
 		case DIFF_STATUS_UNMERGED:

@@ -1712,6 +1720,7 @@ static void wt_shortstatus_status(struct string_list_item *it,
 			 struct wt_status *s)
 {
 	struct wt_status_change_data *d = it->util;
+	const char *from, *to;
 
 	if (d->index_status)
 		color_fprintf(s->fp, color(WT_STATUS_UPDATED, s), "%c", d->index_status);

@@ -1722,15 +1731,30 @@ static void wt_shortstatus_status(struct string_list_item *it,
 	else
 		putchar(' ');
 	putchar(' ');
+
+	if (d->head_path && d->worktree_path)
+		die("BUG: to be addressed in the next patch");
+
+	if (d->head_path) {
+		from = d->head_path;
+		to = it->string;
+	} else if (d->worktree_path) {
+		from = it->string;
+		to = d->worktree_path;
+	} else {
+		from = it->string;
+		to = NULL;
+	}
 	if (s->null_termination) {
-		fprintf(stdout, "%s%c", it->string, 0);
-		if (d->head_path)
-			fprintf(stdout, "%s%c", d->head_path, 0);
+		fprintf(stdout, "%s%c", from, 0);
+		if (to)
+			fprintf(stdout, "%s%c", to, 0);
 	} else {
 		struct strbuf onebuf = STRBUF_INIT;
 		const char *one;
-		if (d->head_path) {
-			one = quote_path(d->head_path, s->prefix, &onebuf);
+
+		if (to) {
+			one = quote_path(from, s->prefix, &onebuf);
 			if (*one != '"' && strchr(one, ' ') != NULL) {
 				putchar('"');
 				strbuf_addch(&onebuf, '"');

@@ -1738,8 +1762,9 @@ static void wt_shortstatus_status(struct string_list_item *it,
 			}
 			printf("%s -> ", one);
 			strbuf_release(&onebuf);
-		}
-		one = quote_path(it->string, s->prefix, &onebuf);
+			one = quote_path(to, s->prefix, &onebuf);
+		} else
+			one = quote_path(from, s->prefix, &onebuf);
 		if (*one != '"' && strchr(one, ' ') != NULL) {
 			putchar('"');
 			strbuf_addch(&onebuf, '"');

@@ -2036,12 +2061,13 @@ static void wt_porcelain_v2_print_changed_entry(
 {
 	struct wt_status_change_data *d = it->util;
 	struct strbuf buf_index = STRBUF_INIT;
-	struct strbuf buf_head = STRBUF_INIT;
+	struct strbuf buf_other = STRBUF_INIT;
 	const char *path_index = NULL;
-	const char *path_head = NULL;
-	char key[3];
+	const char *path_other = NULL;
+	char key[3], status_other;
 	char submodule_token[5];
 	char sep_char, eol_char;
+	int score;
 
 	wt_porcelain_v2_fix_up_changed(it, s);
 	wt_porcelain_v2_submodule_state(d, submodule_token);

@@ -2050,6 +2076,19 @@ static void wt_porcelain_v2_print_changed_entry(
 	key[1] = d->worktree_status ? d->worktree_status : '.';
 	key[2] = 0;
 
+	if (d->head_path && d->worktree_path)
+		die("BUG: to be addressed in the next patch");
+

wt-status.c +2 -3

 	if (s->null_termination) {
 		/*
 		 * In -z mode, we DO NOT C-quote pathnames.  Current path is ALWAYS first.

@@ -2058,7 +2097,6 @@ static void wt_porcelain_v2_print_changed_entry(
 		sep_char = '\0';
 		eol_char = '\0';
 		path_index = it->string;
-		path_head = d->head_path;
 	} else {
 		/*
 		 * Path(s) are C-quoted if necessary. Current path is ALWAYS first.

@@ -2069,17 +2107,17 @@ static void wt_porcelain_v2_print_changed_entry(
 		sep_char = '\t';
 		eol_char = '\n';
 		path_index = quote_path(it->string, s->prefix, &buf_index);
-		if (d->head_path)
-			path_head = quote_path(d->head_path, s->prefix, &buf_head);
+		if (path_other)
+			path_other = quote_path(path_other, s->prefix, &buf_other);
 	}
 

wt-status.c +1 -1

 	else
 		fprintf(s->fp, "1 %s %s %06o %06o %06o %s %s %s%c",
 				key, submodule_token,

@@ -2088,7 +2126,7 @@ static void wt_porcelain_v2_print_changed_entry(
 				path_index, eol_char);
 
 	strbuf_release(&buf_index);
-	strbuf_release(&buf_head);
+	strbuf_release(&buf_other);
 }
 
 /*

wt-status.h +0 -0

index f9330982ac..332ff545aa 100644
@@ -44,10 +44,10 @@ struct wt_status_change_data {
 	int worktree_status;
 	int index_status;

Im afraid "--porcelain=v2" test might be incorrect here, as git status --porcelain=v2` output seems to be too, with this v2 series applied. Test I sent previously[1] fails, and it looks valid.

This is output I now get, with old/deleted file unstaged and new/created file staged with git add -N:

    $ git status --porcelain=v2
    2 .R N... 100644 100644 100644 12f00e90b6ef79117ce6e650416b8cf517099b78 12f00e90b6ef79117ce6e650416b8cf517099b78 R100 original-file new-file

Note "original-file" listed first, where "new-file" listed second (last). According the "v2" documentation[2] (excerpt):

... <path><sep><origPath>

<path> The pathname. In a renamed/copied entry, this
is the path in the index and in the working tree.

...
<origPath> The pathname in the commit at HEAD. This is only
present in a renamed/copied entry, and tells where the renamed/copied contents came from.

If I`m reading this correctly, it should be vice-versa - value from HEAD, being "original-file", should come last, where value from working tree ("new-file") should be first.

Quoted 5 lines

... <path><sep><origPath>

<path> The pathname. In a renamed/copied entry, this
is the path in the index and in the working tree.

Gaah.. as you may see in the other mail when I quoted this (incorrectly). I must have modified this file at some point and thought it was true (my version did not have "and in the worktree").

The "and" is still problematic if you take this very seriously (because in this case index name and worktree name are different) but I think it's ok to ignore that "and" and switch it to "or".

Quoted 7 lines

<origPath> The pathname in the commit at HEAD. This is only
present in a renamed/copied entry, and tells where the renamed/copied contents came from.

If I`m reading this correctly, it should be vice-versa - value from HEAD, being "original-file", should come last, where value from working tree ("new-file") should be first.

Yeah I think the "where the renamed/copied contents came from" clears up my confusion in this format. Back to v1 it is!

... it totally slipped me that documentation is/was pretty strict about <origPath> being HEAD path (exclusively), where I was still expecting it to show renamed working tree "from" value as <origPath> in case of working tree (double) rename, too - where that exact (already renamed in index) path wasnt to be found inside HEAD at all, so the working tree rename couldnt really be shown as "source" and "target" rename pair, strictly following the "porcelain v2" specification... :/

...

I repeat that this looks like the correct approach, making fully described working tree rename detection possible in porcelain in the first place, but also aligning output of "status" --porcelain variants with its default (--long) form.

The presence of worktree rename leads to an interesting situation, what if the same index entry is renamed twice, compared to HEAD and to worktree? We can have that with this setup

echo first > first && git add first && git commit -m first git mv first second # rename reported in "diff --cached"
mv second third # rename reported in "diff-files"

For the long format this is fine because we print two "->" rename lines, one in the "updated" section, one in "changed" one.

For other output formats, it gets tricky because they combine both diffs in one line but can only display one rename per line. The result "XY" column of short format, for example, would be "RR" in that case.

This case either needs some extension in short/porcelain format to show something crazy like

    RR first -> second -> third

or we could show renames as two lines instead of one, for example something like this for short form:

    R  first -> second
     R second -> third

But for now it's safer and simpler to just break the "second -> third" rename pair and show

    RD first -> second
     A third

like we have been showing until now.

Hi Duy,

Quoted 33 lines · Nguyễn Thái Ngọc Duy

The presence of worktree rename leads to an interesting situation, what if the same index entry is renamed twice, compared to HEAD and to worktree? We can have that with this setup

echo first > first && git add first && git commit -m first git mv first second # rename reported in "diff --cached"
mv second third # rename reported in "diff-files"

For the long format this is fine because we print two "->" rename lines, one in the "updated" section, one in "changed" one.

For other output formats, it gets tricky because they combine both diffs in one line but can only display one rename per line. The result "XY" column of short format, for example, would be "RR" in that case.

This case either needs some extension in short/porcelain format to show something crazy like

    RR first -> second -> third

or we could show renames as two lines instead of one, for example something like this for short form:

    R  first -> second
     R second -> third

But for now it's safer and simpler to just break the "second -> third" rename pair and show

    RD first -> second
     A third

Quoted 2 lines

like we have been showing until now.

I lost you a bit here, partially because of what seems to be an incomplete setup script, partially because of this last sentence, as Git v2.15.1 doesn`t seem to be showing this, so not sure about "like we have been showing until now" part...?

Now, still using v2.15.1, let`s see porcelain statuses:

(2) $ git status --porcelain

    RR first -> second

(3) $ git status --porcelain=v2

    2 RR N... 100644 100644 000000 9c59e24b8393179a5d712de4f990178df5734d99 9c59e24b8393179a5d712de4f990178df5734d99 R100 second        first

Here, they both report renames in _both_ index and working tree (RR), but they show "index" renamed path only ("second", in comparison to original value in HEAD, "first").

Im inclined to say this doesnt align with what git status shows, disrespecting add -N (or respecting it only partially, through that second R, but not showing the actual working tree rename, "third").

Without influencing porcelain format, and to fully respect add -N, I believe showing two renames (index and working tree) as two lines would be the correct approach - and thats what default git status` does, too.

Now, let`s examine this patch series v2 outputs:

(1) $ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

renamed: first -> second

Changes not staged for commit:
(use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)

renamed: second -> third

(2) $ git status --porcelain

    RD first -> second
     A third

(3) $ git status --porcelain=v2

    2 RD N... 100644 100644 000000 9c59e24b8393179a5d712de4f990178df5734d99 9c59e24b8393179a5d712de4f990178df5734d99 R100 second        first
    1 .A N... 000000 000000 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 third

Here, porcelain statuses make situation a bit better, as now at least add -N is respected, showing new "tracked" path appearing in the working tree.

But, we now lost any idea about the rename that happened there as well - which Git v2.15.1 porcelain was partially showing (through RR), and which git status still reports correctly - and which we still differ from.

I dont think this looks like what we have been showing until now (unless I misunderstood which exact "now" are we talking about), so I dont see that as a valid argument to support this case.

So, while we still changed output of what we were showing so far to two-line output, it seems there`s no real gain, as it looks like we replaced one partial output (recognize rename, omit path) for the other (recognize path, omit rename).

Finally, let`s see your initial patch v1[1], with my exercise patch[2] on top:

(1) $ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

renamed: first -> second

Changes not staged for commit:
(use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)

renamed: second -> third

(2) $ git status --porcelain

    R  first -> second
     R second -> third

(3) $ git status --porcelain=v2

    2 R. N... 100644 100644 100644 9c59e24b8393179a5d712de4f990178df5734d99 9c59e24b8393179a5d712de4f990178df5734d99 R100 second        first
    2 .R N... 100644 100644 100644 9c59e24b8393179a5d712de4f990178df5734d99 9c59e24b8393179a5d712de4f990178df5734d99 R100 third second

Here, both "--porcelain" outputs (2) and (3) seem to much better replicate what default git status is showing, too - namely separate renames in comparison to HEAD for both "index" (2) and "working tree" (3).

And if you don`t like two lines here in comparison to one (incomplete) line from Git v2.15.1, I would remark that patch series v2 prints two lines as well (so different from v2.15.1 in a same way), but with what looks like inferior output in comparison to v1 shown above, where both renames are correctly recognized and reported - and finally fully compatible with default git status output, too.

And if we really think about it, what v1 shows is what actually happened - and more important, its possible to recreate hypothetical "first -> second -> third" change from there. With v2 output, that is impossible, that information is lost as second line doesnt relate to the first one in any way.

Now, unless Im totally missing something here, the only thing left is that you mentioned v2 approach being "safer and simpler" than v1, something Im not really competent to comment on, but just wanted to provide a second opinion, maybe helping to change your mind in favor of v1 outputs, which seem to be _the_ correct ones...? :)

If not that much more complicated/unsafe, of course.

Thanks, Buga

[1] https://public-inbox.org/git/[email protected]/T/#mf60e88fd351f7ff6a076279794c8343a79835f67
[2] https://public-inbox.org/git/[email protected]/T/#m095c33d69994c6ecb4f1adbf80dd48eab66750d8

Quoted 5 lines

I lost you a bit here, partially because of what seems to be an incomplete setup script, partially because of this last sentence, as Git v2.15.1 doesn`t seem to be showing this, so not sure about "like we have been showing until now" part...?

Yeah I missed a "git add -N third" in the setup. And "until now" was a poor choice of words. It should have been "before 425a28e0a4", where "new files" could not show up, which prevented rename detection in the "Changed bot not staged for commit" section in the first place.
...
Sorry again about "now". Before 425a28e0a4 rename detection would not kick in to find "second -> third" so people wouldn't know about rename anyway.

v3 more or less goes back to v1 after my discussion with Igor about porcelain formats. So 7/7 is not needed anymore. 4/7 becomes 5/6. The meat is still in 6/6, now with some more updates in git-status.txt and to address the comment from Torsten.

v3 more or less goes back to v1 after my discussion with Igor about porcelain formats. So 7/7 is not needed anymore. 4/7 becomes 5/6. The meat is still in 6/6, now with some more updates in git-status.txt and to address the comment from Torsten.

Nguyễn Thái Ngọc Duy (6):
t2203: test status output with porcelain v2 format
Use DIFF_DETECT_RENAME for detect_rename assignments wt-status.c: coding style fix
wt-status.c: catch unhandled diff status codes wt-status.c: rename rename-related fields in wt_status_change_data wt-status.c: handle worktree renames

  Documentation/git-status.txt | 23 ++++++------
  builtin/commit.c             |  2 +-
  diff.c                       |  2 +-
  t/t2203-add-intent.sh        | 72 ++++++++++++++++++++++++++++++++++++++
  wt-status.c                  | 83 ++++++++++++++++++++++++++++----------------
  wt-status.h                  |  5 +--
  6 files changed, 143 insertions(+), 44 deletions(-)

 wt-status.c           | 24 +++++++++++++++++++-----
 wt-status.h           |  1 +
 3 files changed, 35 insertions(+), 5 deletions(-)

t/t2203-add-intent.sh +0 -0

index 1bdf38e80d..41a8874e60 100755