Re: [PATCH] status: handle worktree renames
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Jan 2, 2018, 21:14 UTC
- Message-ID
- <3a8169b4-1d7f-35dc-eb23-49afdaa3bf52@jeffhostetler.com>
- In-Reply-To
- <xmqqh8scnip5.fsf@gitster.mtv.corp.google.com>
On 12/27/2017 1:12 PM, Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> 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 ".R" lines in your 3rd patch series as that keeps porcelain V2 output consistent with the changes that you added to plain and porcelain V1 output. All 3 formats now report 2 types of renames. Having a "RR" line would be more consistent with a "MM" line, but I don't think that happens often enough to define a porcelain V3 format with a 3 path row variant.
I like that we can now show "unstaged renames" (in all 3 formats) as I think that is less confusing to the novice user than a new-file/delete pair.
Having said that, I am a little concerned about us changing V1 and V2 output at all -- we are breaking the porcelain contract we have with scripts. I like the change, so I'm not bothered about it, but others may think differently.
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 possibly 4 pathnames for a file? (merge-base, branch-a, branch-b, worktree)
Jeff