Re: [PATCH] status: handle worktree renames

2018-01-10 Thread Duy Nguyen
On Wed, Jan 3, 2018 at 4:14 AM, Jeff Hostetler wrote: > Also, does this introduce any new cases for reporting conflicts? > I haven't really thought about it too much yet, but if there was a > divergent rename in both branches of a merge, do we now have to handle > showing

Re: [PATCH] status: handle worktree renames

2018-01-02 Thread Jeff Hostetler
On 12/27/2017 1:12 PM, Junio C Hamano wrote: Duy Nguyen writes: Or we disable rename-from-worktree when porcelain v2 is requested (and optionally introduce v3 to support it). Jeff, any preference? Sorry for the delay, I was on vacation last week. I like the "R." and

Re: [PATCH] status: handle worktree renames

2017-12-27 Thread Junio C Hamano
Duy Nguyen writes: >> 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 "" code for HEAD rename would be "R." > while worktree

Re: [PATCH] status: handle worktree renames

2017-12-27 Thread Junio C Hamano
Duy Nguyen writes: > Or we disable rename-from-worktree when porcelain v2 is requested (and > optionally introduce v3 to support it). Jeff, any preference? I actually think disabling rename-from-worktree consistently may be the best way to go.

Re: [PATCH] status: handle worktree renames

2017-12-26 Thread Torsten Bögershausen
On 2017-12-25 11:37, Nguyễn Thái Ngọc Duy wrote: [] > wt-status.c | 24 +++- > wt-status.h | 1 + > 3 files changed, 35 insertions(+), 5 deletions(-) > > diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh > index 1bdf38e80d..41a8874e60 100755 >

Re: [PATCH] status: handle worktree renames

2017-12-25 Thread Duy Nguyen
On Tue, Dec 26, 2017 at 9:11 AM, Duy Nguyen 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 >>

Re: [PATCH] status: handle worktree renames

2017-12-25 Thread Duy Nguyen
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

Re: [PATCH] status: handle worktree renames

2017-12-25 Thread Igor Djordjevic
On 25/12/2017 20:45, Igor Djordjevic wrote: > > I guess an additional test for this would be good, too. ... aaand here it is. Again based on your test, but please double check, I`m not sure if it`s ok to compare file modes like that, expecting them to be the same (hashes should be fine, I

Re: [PATCH] status: handle worktree renames

2017-12-25 Thread Igor Djordjevic
On 25/12/2017 19:26, 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 >

Re: [PATCH] status: handle worktree renames

2017-12-25 Thread Igor Djordjevic
Hi Duy, On 25/12/2017 11:37, 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] status: handle worktree renames

2017-12-25 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