Re: [PATCH v2 7/8] git-p4: decode p4 wildcard characters

gitster@pobox.com wrote on Thu, 24 Feb 2011 08:40 -0800:

Tor Arvid Lund [off-list ref] writes:

quoted

On Thu, Feb 24, 2011 at 1:12 PM, Pete Wyckoff [off-list ref] wrote:
...
Yeah, I was thinking... what happens now if we do:

1) Create "my*file" in linux, and submit.
2) git-p4 sync from windows, and get my%2Afile on windows.
3) modify my%2Afile and do git commit.
4) git-p4 submit

I haven't had time to test right now, but maybe p4 will not recognise
my%2Afile (or try to check it in as my%252Afile (replacing the '%'
character) or something like that? (Or maybe I just haven't had enough
coffee today :-/ )

This shares the same issue as "checking files out on case insensitive
filesystems" topic in the other thread.  "my*file" may not be usable by
the project when renamed to "my%2Afile", so "git-p4 sync" may want to warn
the user about the path when this happens.

And you need to reverse this quoting upon "git-p4 submit".  Does that
happen already?

I have not found any testers to try these things on windows.

We have a separate bug in git-p4 for submitting files with
wildcards, windows or unix.  This could be fixed anytime in
a separate patch; any takers?

Another unrelated p4-linux-only bug is this:

    arf$ echo hello > my%file
    arf$ p4 add -f my%file
    //depot/my%25file#1 - opened for add
    arf$ p4 submit -d 'add my file'
    Submitting change 1.
    Locking 1 files ...
    add //depot/my%25file#1
    Change 1 submitted.
    arf$ p4 sync
    File(s) up-to-date.
    arf$ p4 open my%file
    my%file - file(s) not on client.
    arf$ p4 open my%25file
    //depot/my%25file#1 - opened for edit

I can create and add my%file, but cannot edit or delete it.  The
"-f" option does not help.  It can be edited/deleted using the %25
expansion.  I found this same problem on Windows.

Conclusion:  p4 is buggy and incomplete with respect to wildcard
characters in filenames already.  This particular change does not make
anything worse, and fixes a problem seen in the wild for a filename with
"@".  I'd like to hope p4 gets fixed at which point this % issue goes
away, and we can decide what to do with * on windows, following their
lead.

		-- Pete