Johan Herland <johan@xxxxxxxxxxx> writes: > On Monday 10 August 2009, Daniel Barkalow wrote: > ... >> The only way I've been able to come up with to support this at all >> usefully is to have a bunch of helper-specific options that specify what >> the helper needs to know about the locations you consider to be part of >> the project and an option that tells git that this remote uses the p4 >> helper. I'm not sure what makes sense for other helpers, but the case I >> actually use needs something like what's in this patch. > > I'm somewhat agnostic on this issue. At the moment, I follow the P4 cues, > and use a config like this: > > [remote "foo"] > vcs = cvs > cvsRoot = ":pserver:user@xxxxxxxxxxxxxxxxxxxxxx/var/cvs/cvsroot" > cvsModule = "bar" > ... > > But I could just as well use a config like this instead: > > [remote "foo"] > url = "cvs::pserver:user@xxxxxxxxxxxxxxxxxxxxxx/var/cvs/cvsroot#bar" > ... > > Either is fine with me, although I suspect users might find the > current/first alternative easier to parse. Ah, ok, that is a much better (rather, easier to understand for _me_) example to illustrate what Daniel meant, and I can well imagine P4 counterpart of cvsRoot may resemble an URL even less than your cvsRoot example does. If the foreign system uses a single string as "the string to identify location", like the latter (which is a good example, even though I do not think a CVS folks write a reference to a module like you wrote), then I think it makes sense to use that form as remote.$name.url. But if naming a location with a single simple string is an alien notion to the foreign system, I agree with Daniel that we do not gain much by trying to shoehorn them into a single remote.$name.url configuration. -- 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