p.s. An extra note for the casual reader, just in case: On 28/12/2017 01:50, Igor Djordjevic wrote: > > ... 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 wasn`t to be found inside HEAD at > all, so the working tree rename couldn`t 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. Wherever "working tree rename detection" is discussed above, it`s all still about renamed file `git add -N` case only (where old name, appearing "deleted" from HEAD/index, is not staged yet), not some new functionality where renamed file inside working tree is instantly / magically recognized without being staged in the first place.
