On Wed, Dec 27, 2017 at 1:14 AM, Igor Djordjevic
<igor.d.djordjevic@xxxxxxxxx> wrote:
> I`m 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.
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".
> ...
> <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!
--
Duy
