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