Tor Arvid Lund <torarvid <at> gmail.com> writes:
> Well, I see what you're trying to do, but I would not want to see that
> patch in the official script, because some (most?) people (myself, at
> least) use git-p4 to clone single projects out of a perforce depot
> that may contain many projects. I do this myself by doing:
>
> git p4 clone //depot/path/to/projectX <at> all
>
> I usually use one clientspec in perforce, and I do not want to change
> that... With your patch, I would be in trouble since my clientspec
> contains "//depot/..." (followed by a lot of lines starting with '-')
Well, does this mean that if you try to sync the client in perforce (visual or
command line), you will sync all the projects?
In that case, git p4 will require significant effort to satisfy both of us :-)
Unfortunatly, it seems I'm in minory group of git-p4 users...
i would propose to use both command-line arguments and a client spec
to create a correct filter of what should be synced/cloned.
BTW, it looks this script does not honor neither the order of paths
in the spec (which can be important) nor mapping of the files to a local tree.
> If you want to fix it, you might want to rename clientSpecDirs to
> clientSpecEntries or something like that.
For now, I just commented out two lines in the run() procedure:
#if not p.endswith("/"):
# p += "/"
> Btw... Am I understanding correctly what it is you wish to accomplish?
> I'm guessing that you have a perforce server with a client spec set
> up, and you want to sync everything on the entire server according to
> that client spec?
yes. Client spec completely defines the project layout for me.
It contains paths to some components that are mapped to the
client working tree.
Just if your CS contain
//depot/path/to/projectX/... //CLIENT/...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html