Re: [RFC/PATCH 0/4] working tree operations: support superprefix

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

 



Resending original as plain text as git@xxxxxxxxxxxxxxxxx rejected HTML encoding as potential virus. Apologies for dupes in inbox. Hopefully this works.

In response to a post at:

https://groups.google.com/forum/#!topic/git-users/BVLcKHhSUKo

I was asked to post here to explain a potential problem with current modules implementation. Apologies if I am posting in the wrong place... so good bad or otherwise here goes:

+-------------------------------
With:

git push origin branchname

or

git push server2 branchname

I can push or pull from multiple servers so no problem as git supports this.

Now the problem with use of submodules

submodules are listed:

submodule.directory_to_
checkout/proj1_dir.url=https://git.someserver1/git/proj1_dir <https://git.someserver1/git/proj1_dir>

but if say I want to pull from some server 2 and do a

git submodule update --init --recursive

what I would get is from someserver1 not someserver2 as there is no "origin" support for submodules. Is this correct? If so can origin support be added to submodules?
+-------------------------------

So above was post from google group. Maybe above is enough to explain the problem that can result, but if not here is a discussion as to why this can be confusing resulting to pushing or pulling from the incorrect server.

Lets say projects starts at origin on https://server0.org. Project is then brought in house to server https://indhouse.corp by developer A.

Developer A then changes the submodule projects to point to indhouse and changes submodules in super project to point to indhouse so everything is great.

Then Developer B clones from indhouse makes changes to submodule1 and submodule1 and pushes them to indhouse. Dev A tells Dev B hey thoes changes are great why don't you push to public server0 so every one can get thoes changes. Dev B then git push origin branch_name on submodule1 and push origin on submodule 2 and superproject. And everything is great ... right?

Yes by now those who know git know what dev B forgot or more to the point what git does not support in a "clean" way. For those who don't enter the life of dev C

So dev C clones from server0 and performs a git submodule update --init --recursive. Now Dev C is on the www and can't see indhouse.corp and ... kerpow... Dev B and Dev C just experienced one of the many SW mines on the battlefield.

I ask that git devs first see if I am correct with this assessment as I could be wrong... maybe there is a way of doing this... and if not add a feature to git to handle submodules and multiple origins cleanly.... and yes beating dev B with rubber chicken might be a solution though I am looking for a slightly better option.



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