On 27/12/2017 02:06, Duy Nguyen wrote:
>
> > ... <path><sep><origPath>
> >
> > <path> 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 some point and
> thought it was true (my version did not have "and in the worktree").
Ah, this explains a lot... :) I got really confused with your v2, it
felt as the series took a strange turn, and in a kind of a subtle way :P
> The "and" is still problematic if you take this very seriously
> (because in this case index name and worktree name are different) but
> I think it's ok to ignore that "and" and switch it to "or".
Yes, I agree, and the change does feel like a good thing. But, I also
now hope this doesn`t break any expectations, because... (read below)
> > <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.
> >
> > If I`m reading this correctly, it should be vice-versa - value from
> > HEAD, being "original-file", should come last, where value from
> > working tree ("new-file") should be first.
... 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 see now that your initial reply[1] was talking about this, but I
didn`t focus on it much as you replied to it yourself shortly
afterwards, and later v2 of the series came up.
Might be this is where you changed your offline documentation
version, too, as that is what the sample patch was about :)
> Yeah I think the "where the renamed/copied contents came from" clears
> up my confusion in this format. Back to v1 it is!
I see you addressed this by loosening the restriction here a bit, too,
making <origPath> be "pathname in the commit at HEAD _or in the index_",
in your "[PATCH v3 6/6] wt-status.c: handle worktree renames"[2].
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.
Hopefully, on top of everything positive, it also doesn`t break
anything (too much?)... :P Latest revision should now provide all the
necessary ingredients to resolve what happened, for the (small?)
price of tweaking previous expectations a bit.
Regards, Buga
[1] https://public-inbox.org/git/CACsJy8A=jZ9LAuM50GVjNT5gtdiYYMyMuPBSrJFO4LmKVQsETQ@xxxxxxxxxxxxxx/T/#mf2f5ae672ec6f4e1abecbd5fe65283e9d8fbed57
[2] https://public-inbox.org/git/20171227101839.26427-7-pclouds@xxxxxxxxx/T/#u
