Tor Arvid Lund [off-list ref] writes:
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?
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