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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 20, 2012 at 10:34 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
> Am 20.05.2012 00:51, schrieb Jon Seymour:
>> On Sun, May 20, 2012 at 4:56 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
>>> Am 19.05.2012 06:40, schrieb Jon Seymour:
>>>
>>> Just a small nit: I'd prefer to replace the 4 occurrences of the term
>>> "supermodule" with "superproject".
>>
>> Sure. I can't argue with precedent, of course, but I guess I was
>> favouring the consistency in the suffixes used with sub and super.
>
> No big deal, but in recent posts "superproject" has been used and
> the similarity between "supermodule" and "submodule" fooled me when
> I read your RFC patch. So even though a superproject might be the a
> submodule of another superproject, I'm all for using the term
> "superproject" to make the distinction obvious.
>
>>> So no objection on the code changes from my side.
>>
>> I noticed one relative case that is not handled properly yet, but
>> there is a workaround. If the superproject's origin URL is of the
>> form: foo/bar (a case I actually have myself for reasons I can explain
>> if you want me to), then the correct rule doesn't get matched by
>> .*/*). The workaround is for the user to change foo/bar style origin
>> URLs to ./foo/bar.
>>
>> Let me know if I should fix this case now too.
>
> Me thinks that this is subject for a subsequent patch. Having the
> URL of the superproject *below* the root directory of the
> superproject seems like a rather odd case which warrants a fix of
> its own ;-)

The situation arises in my case because my working directory (which
has git controlled elements) contains a subdirectory called mnt with a
symbolic link called git which points to the actual location of my git
respositories. So, in this case:

    mnt/git/public/work.git -> /var/git/public/work.git

So, if I want to set my origin to be my public git repositories, I naturally do:

   git remote set-url origin mnt/git/public/work.git

I'll wait to hear Junio's preference with regard to how I should split
the patches up before posting v3 that includes support for foo/bar in
addition to ../foo/bar and ./foo/bar.

Regards,

jon.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]