Re: [PATCH] status: handle worktree renames

> On Mon, Dec 25, 2017 at 07:26:27PM +0100, Igor Djordjevic wrote:
>> 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.
>
> 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
>
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index 81cab9aefb..3da10020aa 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -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?).