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

[Pete Wyckoff <pw@padd.com>]

gitster@pobox.com wrote on Thu, 24 Feb 2011 08:40 -0800:
> Tor Arvid Lund <torarvid@gmail.com> writes:
> 
> > On Thu, Feb 24, 2011 at 1:12 PM, Pete Wyckoff <pw@padd.com> 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