Re: [PATCH v2 2/2] submodule: fix handling of superproject with relative origin URLs

From: Junio C Hamano <gitster@pobox.com>
Date: May 21, 2012, 02:08 UTC
Message-ID: <7vfwau9tgc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1337468428-26155-2-git-send-email-jon.seymour@gmail.com>

Jon Seymour <jon.seymour@gmail.com> writes:

> Prior to this change, an operation such as git submodule add, init or
> sync produced the wrong result when the origin URL of the superproject
> was itself a relative URL.

If you say you are "fixing" something in the title, it is already known to the reader that a broken behaviour exists in the code without the patch in question. Instead of spending four useless words "Prior to this change", could "the wrong result" be clarified with either saying "wrong in what way" and/or "because of this and that reason"?

In the case of this patch, you explain "because..." part in the second paragraph (which is good), so

	An operation such as A and B does this when it should do that
	instead.

stated in the present tense, as a statement of the fact, is sufficient. "does this instead of that, which is wrong" is a lot more important.

> Note that superproject relative origin URLs of the form foo/bar
> are still not handled correctly.

I am not sure what the use case of such a layout is. A project that has a "bar" repository as its superproject (or its one of submodules for that matter) may advertise that the other repository lives at ../bar.git, so that when these two projects are served at a random hosting service, such a cross-project pointer does not have to be rewritten as long as their relative location at the hosting service remains the same. But what does it mean to say a related "foo" project lives in foo/bar.git directory relative to one project in the first place? Does the project's $GIT_DIR/ have a "foo" directory next to its "refs" and "objects"? Probably I am missing what you are trying to achieve. Puzzled.