Re: [PATCH 2/2] git-p4: Add copy detection support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pete,

On Mon, Feb 7, 2011 at 11:11 AM, Vitor Antunes <vitor.hda@xxxxxxxxx> wrote:
> Hi Pete,
>
> On Sun, Feb 6, 2011 at 10:05 PM, Pete Wyckoff <pw@xxxxxxxx> wrote:
>>> (Copying help text:
>>>       The -t flag makes the source file's filetype propagate to the target
>>>       file.  Normally, the target file retains its previous filetype.
>>>       Newly branched files always use the source file's filetype.  The
>>>       filetype can still be changed before 'p4 submit' with 'p4 reopen'.
>>> )
>>>
>>> Since in git we're only considering newly branched files, I think in
>>> this case "-t" will not add anything. In fact, what is being done here
>>> is detecting exec bit changes from source to target files - we're not
>>> trying to force P4 to use the source's exec bit. Do you agree?
>>
>> That sounds fine to me.  The code seemed to indicate that
>> sometimes the destination file exists.
>
> I've basically copied the code from the rename detection part and
> adapted it to copying. Nevertheless, even if git detects a copy to a
> already existing file I think that the integrate command should behave
> correctly. I should create a test case for this, though.
>
>>> +            elif modifier == "C":
>>> +                src, dest = diff['src'], diff['dst']
>>> +                p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
>>> +                if diff['src_sha1'] != diff['dst_sha1']:
>>> +                    p4_system("edit \"%s\"" % (dest))
>>> +                if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
>>> +                    filesToChangeExecBit[dest] = diff['dst_mode']
>>> +                os.unlink(dest)
>>> +                editedFiles.add(dest)
>>
>> If you're happy the dest never exists, you may be able to get rid
>> of the edit step and the mode-change check entirely.  As long as
>> you've tested this, you're the expert here.  The change makes
>> sense overall.
>
> I'm not that happy with this... and I'm no expert! I will really need
> to test this possibility. Just need to understand how I can make git
> detect a copy to an existing file... :)

I've tried to trick git into detecting a copy over an existing file by
replacing a file with the contents of another file. But git is not
detecting this as a copy. How can I make git detect a copy over an
existing file?

After re-reading your answer I got the feeling that this SHA diff code
may have been misinterpreted. So, just in case it was, here is the
full history.
Originally the code always opened the files for editing just in case
there was a patch to be applied late,r. This makes sense, because git
can detect a rename (or copy) even if the files differ. But doing this
would create an "unclean" integration in the revision graph. So, what
I thought was "if we have available the SHA of the origin and
destination files in diff-tree output why not compare them before
opening the file for editing?" And that was the only purpose for this
comparison.

-- 
Vitor Antunes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]