Stefan Beller <sbel...@google.com> writes:

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

Reply via email to