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

[Jon Seymour <jon.seymour@gmail.com>]

On Mon, May 21, 2012 at 12:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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"?
>

I hope v3 is closer to what you would like to see.

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

I have tried to explain the use case again in 4/4 of the v3 patch (my
previous attempt
was in a previous reply to one of Jen's posts). I don't claim that
this is a common
use case at all, but it is a use case that I have used several times myself.

It is particularly useful in cases where there is a need to regularly
synchronize
a collection of git repos and other files across an "air gap" (for example, via
an intermediary USB drive) where one of the repos being synchronized is the
synchronization toolset itself.

In this case, it may well be that the origin repo for a particular
toolset instance
itself is actually located on a USB drive whose physical location changes as
the removable device used to  update the tool set changes.

The user may choose to manage the relative location of the USB drive with a
symbolic link (relative to the toolset) rather than a git origin URL.
(The advantage of
using a symbolic link in this case is that you can update the actual physical
location of the USB drive with a single update to a single symbolic
link - this may
be more convenient in cases where are multiple git repos that need to be synced
to the USB or if there are resources other than git repos on the USB).

So, for example, suppose the toolset is managed within ~/tools with directories
such as:

  ~/tools/bin
  ~/tools/lib

then, perhaps the origin copy of the toolset is found by:

  ~/tools/mnt/usb -> /media/MY_USB_DEVICE/tools

remote.origin.url in ~/tools/.git/config might refer to mnt/usb/tools so that
if the device occasionally changes to /media/YOUR_USB_DEVICE/tools
then this can be accomodated by updating a single symbolic link
(e.g. ~/tools/mnt/usb)

Apologies if this explanation is not clear enough.

Again, I don't claim it is a common use case, but then I don't see
any harm with git supporting it either since it doesn't require much
work.

jon