From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Alex Vandiver <alexmv@dropbox.com>
Subject: Re: [PATCH v2 6/7] wt-status.c: handle worktree renames
Date: Thu, 28 Dec 2017 01:50:29 +0100 [thread overview]
Message-ID: <fb29d5bf-daae-fa8b-b787-e536cd5f98c8@gmail.com> (raw)
In-Reply-To: <CACsJy8Dn_XKA8=iLRZpj2EKYOSZqHT0jw9o_HzPH_vncGGeCCQ@mail.gmail.com>
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@mail.gmail.com/T/#mf2f5ae672ec6f4e1abecbd5fe65283e9d8fbed57
[2] https://public-inbox.org/git/20171227101839.26427-7-pclouds@gmail.com/T/#u
next prev parent reply other threads:[~2017-12-28 0:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-23 2:42 [BUG] File move with `add -N` shows as rename to same name Alex Vandiver
2017-12-25 9:00 ` Duy Nguyen
2017-12-25 10:37 ` [PATCH] status: handle worktree renames Nguyễn Thái Ngọc Duy
2017-12-25 18:26 ` Igor Djordjevic
2017-12-25 19:45 ` Igor Djordjevic
2017-12-25 21:49 ` Igor Djordjevic
2017-12-26 2:11 ` Duy Nguyen
2017-12-26 2:53 ` Duy Nguyen
2017-12-27 18:17 ` Junio C Hamano
2017-12-27 18:12 ` Junio C Hamano
2018-01-02 21:14 ` Jeff Hostetler
2018-01-10 9:26 ` Duy Nguyen
2017-12-26 9:10 ` [PATCH v2 0/7] Renames in git-status "changed not staged" section Nguyễn Thái Ngọc Duy
2017-12-26 9:10 ` [PATCH v2 1/7] t2203: test status output with porcelain v2 format Nguyễn Thái Ngọc Duy
2017-12-26 9:10 ` [PATCH v2 2/7] Use DIFF_DETECT_RENAME for detect_rename assignments Nguyễn Thái Ngọc Duy
2017-12-26 9:10 ` [PATCH v2 3/7] wt-status.c: coding style fix Nguyễn Thái Ngọc Duy
2017-12-26 9:10 ` [PATCH v2 4/7] wt-status.c: rename wt_status_change_data::score Nguyễn Thái Ngọc Duy
2017-12-26 9:10 ` [PATCH v2 5/7] wt-status.c: catch unhandled diff status codes Nguyễn Thái Ngọc Duy
2017-12-26 9:10 ` [PATCH v2 6/7] wt-status.c: handle worktree renames Nguyễn Thái Ngọc Duy
2017-12-26 18:14 ` Igor Djordjevic
2017-12-27 1:06 ` Duy Nguyen
2017-12-28 0:50 ` Igor Djordjevic [this message]
2017-12-28 2:14 ` Igor Djordjevic
2017-12-26 9:10 ` [PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format Nguyễn Thái Ngọc Duy
2017-12-26 22:14 ` Igor Djordjevic
2017-12-27 0:49 ` Duy Nguyen
2017-12-27 23:53 ` Igor Djordjevic
2017-12-27 10:18 ` [PATCH v3 0/6] Renames in git-status "changed not staged" section Nguyễn Thái Ngọc Duy
2017-12-27 10:18 ` [PATCH v3 1/6] t2203: test status output with porcelain v2 format Nguyễn Thái Ngọc Duy
2017-12-27 10:18 ` [PATCH v3 2/6] Use DIFF_DETECT_RENAME for detect_rename assignments Nguyễn Thái Ngọc Duy
2017-12-27 10:18 ` [PATCH v3 3/6] wt-status.c: coding style fix Nguyễn Thái Ngọc Duy
2017-12-27 10:18 ` [PATCH v3 4/6] wt-status.c: catch unhandled diff status codes Nguyễn Thái Ngọc Duy
2017-12-27 10:18 ` [PATCH v3 5/6] wt-status.c: rename rename-related fields in wt_status_change_data Nguyễn Thái Ngọc Duy
2017-12-27 10:18 ` [PATCH v3 6/6] wt-status.c: handle worktree renames Nguyễn Thái Ngọc Duy
2017-12-28 0:59 ` [PATCH v3 0/6] Renames in git-status "changed not staged" section Igor Djordjevic
2018-01-02 21:22 ` Jeff Hostetler
2017-12-26 18:04 ` [PATCH] status: handle worktree renames Torsten Bögershausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb29d5bf-daae-fa8b-b787-e536cd5f98c8@gmail.com \
--to=igor.d.djordjevic@gmail.com \
--cc=alexmv@dropbox.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).