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

From: Jon Seymour <jon.seymour@gmail.com>
Date: May 21, 2012, 13:52 UTC
Message-ID: <CAH3AnrrNTrMcd6ZaUKqt9EgGvbRGBaqiqsPmECZAXZnahzr7OA@mail.gmail.com>
In-Reply-To: <7vfwau9tgc.fsf@alter.siamese.dyndns.org>

On Mon, May 21, 2012 at 12:08 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

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

Show 13 quoted lines

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