From: "Mazo, Andrey" <amazo@checkvideo.com>
To: "luke@diamand.org" <luke@diamand.org>
Cc: "chenbin.sh@gmail.com" <chenbin.sh@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
"gitster@pobox.com" <gitster@pobox.com>,
"merlorom@yahoo.fr" <merlorom@yahoo.fr>,
"vitor.hda@gmail.com" <vitor.hda@gmail.com>,
"Mazo, Andrey" <amazo@checkvideo.com>
Subject: Re: git-p4: default behavior for handling moves?
Date: Tue, 8 Jan 2019 00:56:51 +0000 [thread overview]
Message-ID: <20190108005634.1647-1-amazo@checkvideo.com> (raw)
In-Reply-To: <CAE5ih7987J2WXdCJvs2e3hOn3zucpE6gsr4JJtxO+XE5=K2G_Q@mail.gmail.com>
> git-p4 can map a "git move" operation to a Perforce "move" operation.
> But by default this is disabled. You then end up with a P4 commit
> where the file is deleted, and a fresh file is created with the same
> contents at the new location at revision #1.
>
> Rename detection gets enabled either with the "-M" option, or with
> some config variables, git-p4.detectCopies and git-p4.detectRenames.
>
> I've been tripped up by this, and I actually know about it, and I know
> other people have been as well.
>
> Should we switch the default over so that it's enabled by default? I
> can't think of any reason why you wouldn't want it enabled.
I have it enabled in my ~/.gitconfig,
so enabling it by default makes total sense to me.
Regarding potential problems,
I occasionally get a wrong "source" file detection.
(e.g. there was `cp a b ; git add b`, but some other file "c" is selected as the source instead)
Or there is a "copy/move" detected, when there was actually none.
But I've only seen this with quite small files (like a trivial one line shell script) or binaries,
and mostly because I have git-p4.detectCopiesHarder set as well as a pretty aggressive git-p4.detectCopies threshold.
(normally 30%, but down to 10% at times to make sure a copy/move is really detected)
But anyway, enabling both git-p4.detect{Copies,Renames}
with default 50% similarity index makes sense to me.
It's probably worth adding command-line options to override the new to-be defaults though.
A more conservative approach like only enabling git-p4.detectRenames = 70% is an option too.
>
> I think the rename code was first introduced around 2011 by Vitor.
>
> Another option is to add a warning, but people just ignore warnings!
When such a warning would be shown?
Just before `p4 submit`?
I think, It might be hard to notice for large changesets.
Thank you,
Andrey
next prev parent reply other threads:[~2019-01-08 0:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 12:50 git-p4: default behavior for handling moves? Luke Diamand
2019-01-08 0:56 ` Mazo, Andrey [this message]
2019-01-09 22:41 ` Vitor Antunes
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=20190108005634.1647-1-amazo@checkvideo.com \
--to=amazo@checkvideo.com \
--cc=chenbin.sh@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=luke@diamand.org \
--cc=merlorom@yahoo.fr \
--cc=vitor.hda@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).