Junio C Hamano <gitster@xxxxxxxxx> writes:
>> With one positional option, git-subtree add simply assumes
>> it's a refspec. Is there an easy way to check whether a string is a
>> proper refspec? Even better would be a way to check if a string is a
>> path to a git repository.
>
> Do you literally mean "a path to a repository" in the above, or do
> you mean "a remote that is like what is accepted by 'git fetch'"?
It's the latter as git-subtree calls git-fetch to do the work of
getting revisions.
> On the other hand, if you mean the command takes a remote and an
> optional list of refspecs just like "git fetch" does, then I am not
> sure it is a good design in the first place to allow "refspecs
> only", if only to keep the interface similar to "git fetch" (you
> cannot omit remote and give refspecs, as you cannot interpret
> refspecs without knowing in the context of which remote they are to
> be interpreted).
If just a refspec is given, git-subtree does a rev-parse in the current
directory and that seems to work fine. It's what I as a user would
expect to happen.
> I would imagine you could disambiguate and default to "origin" or
> something when you guessed that remote was omitted if you really
> wanted to, with a syntacitical heuristics, such as "a refspec will
> never have two colons in it", "a URL tends to begin with a short
> alphabet word, a colon and double-slash", etc.
Hmm...I haven't added code to verify the repository/remote argument if
given. I suppose a rev-parse --verify would suffice?
-David
--
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