git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Brian J. Davis" <bitminer@gmail.com>
To: sbeller@google.com
Cc: bmwill@google.com, git@vger.kernel.org, novalis@novalis.org
Subject: Re: [RFC/PATCH 0/4] working tree operations: support superprefix
Date: Fri, 13 Jan 2017 11:56:26 -0600	[thread overview]
Message-ID: <295f0f45-e5ba-f6fd-57e4-6bf684617f13@gmail.com> (raw)
In-Reply-To: <152c0fbf-084c-847f-2a30-a45ea3dd26f2@gmail.com>

Resending original as plain text as git@verger.kernel.org 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.

      parent reply	other threads:[~2017-01-13 17:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10  1:45 [RFC/PATCH 0/4] working tree operations: support superprefix Stefan Beller
2017-01-10  1:45 ` [PATCH 1/4] read-tree: use OPT_BOOL instead of OPT_SET_INT Stefan Beller
2017-01-10 20:41   ` Junio C Hamano
2017-01-10  1:45 ` [PATCH 2/4] t1000: modernize style Stefan Beller
2017-01-10 20:37   ` Junio C Hamano
2017-01-10 20:43     ` Stefan Beller
2017-01-10 22:01       ` Junio C Hamano
2017-01-10  1:45 ` [PATCH 3/4] t1001: " Stefan Beller
2017-01-10  1:45 ` [PATCH 4/4] unpack-trees: support super-prefix option Stefan Beller
2017-01-11 21:32   ` Junio C Hamano
2017-01-11 22:12     ` Stefan Beller
2017-01-11 23:28       ` Junio C Hamano
2017-01-11 23:57         ` Stefan Beller
2017-01-12  0:12     ` [PATCHv2 " Stefan Beller
2017-01-12 21:40       ` Junio C Hamano
2017-01-12 22:19         ` Stefan Beller
     [not found] ` <152c0fbf-084c-847f-2a30-a45ea3dd26f2@gmail.com>
2017-01-13 17:56   ` Brian J. Davis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=295f0f45-e5ba-f6fd-57e4-6bf684617f13@gmail.com \
    --to=bitminer@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=novalis@novalis.org \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).