Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

2017-12-27 Thread Igor Djordjevic
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 being HEAD path (exclusively), where I was still > expecting it to show renamed working tree "from" value as > in

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

2017-12-27 Thread Igor Djordjevic
On 27/12/2017 02:06, Duy Nguyen wrote: > > > ... > > > >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

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

2017-12-26 Thread Duy Nguyen
On Wed, Dec 27, 2017 at 1:14 AM, Igor Djordjevic 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

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

2017-12-26 Thread Igor Djordjevic
Hi Duy, On 26/12/2017 10:10, Nguyễn Thái Ngọc Duy wrote: > 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

[PATCH v2 6/7] wt-status.c: handle worktree renames

2017-12-26 Thread Nguyễn Thái Ngọc Duy
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