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

From: Pete Wyckoff <pw@padd.com>
Date: Feb 27, 2011, 21:16 UTC
Message-ID: <20110227211622.GA15075@arf.padd.com>
In-Reply-To: <7voc612xns.fsf@alter.siamese.dyndns.org>

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

Show 23 quoted lines

> 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