Re: [PATCH] submodule--helper: normalize funny urls

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2016, 15:24 UTC
Message-ID: <xmqqy41lr87v.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20161017221623.7299-1-sbeller@google.com>

Stefan Beller <sbeller@google.com> writes:

Show 9 quoted lines

> Currently a URL for the superproject ending in
>
> (A)    .../path/to/dir
> (B)    .../path/to/dir/
> (C)    .../path/to/dir/.
> (D)    .../path/to/dir/./.
> (E)    .../path/to/dir/.///.//.
>
> is treated the same in (A) and (B), but (C, D, E) are different.

You may know what you meant to say with "treated", but the readers do not know "treated" in what situation you are talking about. We need to tell the readers that the bug being fixed is about resolving a relative URL "../<something>" off of the URL of the superproject to compute the remote URL for a submodule repository.

> We never produce the URLs in (C,D,E) ourselves, they come to use, because
> the user used it as the URL for cloning a superproject.
> Normalize these paths.

As you know the externally-visible impact of this change (which I asked you, but didn't see an on-list answer to, by the way), please describe what this means to the end user in the log message. It is normally done in an earlier part of the log message to describe the problem being solved and its background.

If I understand the issue correctly, it may go like this:

	The remote URL for the submodule can be specified relative
	to the URL of the superproject in .gitmodules.  A top-level
	git://site.xz/toplevel.git can specify in its .gitmodules

		[submodule "sub"]
			url = ../submodule.git
			path = sub

	to say that git://site.xz/submodule.git is where the
	submodule bound at its "sub/" is found.

	However, when the toplevel is cloned like this:

		git clone git://site.xz/toplevel.git/. top

	i.e. the toplevel specifies its URL with trailing "/.", the
	code set the URL to git://site.xz/toplevel.git/submodule.git
	for the submodule, which is nonsense.  This was because the
	logic failed to treat trailing "/." any differently from
	trailing "/<anything-without-slash>" when resolving a
	relative URL "../<something>" off of it.  Stripping "/." at
	the end does *not* take you one level up, even though
	stripping "/<anything-without-slash>" does!
	
And then describe the solution/bugfix, listing A-C (or A-E) and
telling that these will be treated the same way.