On Tue, Dec 26, 2017 at 9:11 AM, Duy Nguyen <pclo...@gmail.com> wrote: > 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?).
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. -- Duy
