Hello,
Is there any plan for the git-p4.py script to support the "*" wildcard in a p4 client?
The specific test that exposes this unsupported feature: ./t9809-git-p4-client-view.sh ... ok 4 - unsupported view wildcard *
Thanks, -Matt
threads / discuss / 30452
git-p4: planned view wildcard support
Subject: git-p4: planned view wildcard support
Re: git-p4: planned view wildcard support
matthew.mendell@gmail.com wrote on Sun, 06 May 2012 16:46 -0700:
Show 7 quoted lines
> Is there any plan for the git-p4.py script to support the "*" wildcard > in a p4 client? > > The specific test that exposes this unsupported feature: > ./t9809-git-p4-client-view.sh > ... > ok 4 - unsupported view wildcard *
It hasn't been on anybody's priority list so far that I know, but this would be not too hard to implement in theory.
The code changes would need to alter just one class. In View.Path, functions Path.find_wildcards, match_wildcards and fill_in_wildcards, if you're interested in giving it a try.
Can you constrain your use of "*" a bit? What makes these wildcards difficult is all the edge cases. For instance, is there ever more than one "*"? Is it combined with "..."? Are there multiple lines in the client spec with wildcards? Some abstracted examples would be interesting.
-- Pete
Re: git-p4: planned view wildcard support
On Mon, May 7, 2012 at 3:44 AM, Pete Wyckoff <pw@padd.com> wrote:
Show 23 quoted lines
> matthew.mendell@gmail.com wrote on Sun, 06 May 2012 16:46 -0700: >> Is there any plan for the git-p4.py script to support the "*" wildcard >> in a p4 client? >> >> The specific test that exposes this unsupported feature: >> ./t9809-git-p4-client-view.sh >> ... >> ok 4 - unsupported view wildcard * > > It hasn't been on anybody's priority list so far that I know, but > this would be not too hard to implement in theory. > > The code changes would need to alter just one class. In > View.Path, functions Path.find_wildcards, match_wildcards and > fill_in_wildcards, if you're interested in giving it a try. > > Can you constrain your use of "*" a bit? What makes these > wildcards difficult is all the edge cases. For instance, is > there ever more than one "*"? Is it combined with "..."? Are > there multiple lines in the client spec with wildcards? Some > abstracted examples would be interesting. > > -- Pete
Hi Pete,
Yeah, I have been perusing the code and would like to give it a shot. Is it ok to initially add partial support for the easy cases? My usage of "*" is straight forward:
//depot/project/* //my_clientspec/depot/project/*
Thanks, -Matt
Re: git-p4: planned view wildcard support
matthew.mendell@gmail.com wrote on Mon, 07 May 2012 08:19 -0700:
Show 28 quoted lines
> On Mon, May 7, 2012 at 3:44 AM, Pete Wyckoff <pw@padd.com> wrote: > > matthew.mendell@gmail.com wrote on Sun, 06 May 2012 16:46 -0700: > >> Is there any plan for the git-p4.py script to support the "*" wildcard > >> in a p4 client? > >> > >> The specific test that exposes this unsupported feature: > >> ./t9809-git-p4-client-view.sh > >> ... > >> ok 4 - unsupported view wildcard * > > > > It hasn't been on anybody's priority list so far that I know, but > > this would be not too hard to implement in theory. > > > > The code changes would need to alter just one class. In > > View.Path, functions Path.find_wildcards, match_wildcards and > > fill_in_wildcards, if you're interested in giving it a try. > > > > Can you constrain your use of "*" a bit? What makes these > > wildcards difficult is all the edge cases. For instance, is > > there ever more than one "*"? Is it combined with "..."? Are > > there multiple lines in the client spec with wildcards? Some > > abstracted examples would be interesting. > > Yeah, I have been perusing the code and would like to give it a shot. > Is it ok to initially add partial support for the easy cases? > My usage of "*" is straight forward: > > //depot/project/* //my_clientspec/depot/project/*
That one does seem like it wouldn't be too hard. Similar to trailing "...", but matching only one path component.
As long as git-p4 can reliably detect when it can deal with a *, I think partial support would be just fine.
I'll help think about test cases and such once you have some code that's ready to look at. Thanks!
-- Pete