Re: git subtree error (just how do you expect me to merge 0 trees?)

From: greened@obbligato.org <greened@obbligato.org>
Date: Jan 1, 2013, 04:04 UTC
Message-ID: <87d2xpwnty.fsf@waller.obbligato.org>
In-Reply-To: <7v7gnxd24h.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

>> 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.

Show 7 quoted lines

> 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.

Show 5 quoted lines

> 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