git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Levedahl <mlevedahl@gmail.com>
To: gitster@pobox.org
Cc: git@vger.kernel.org
Subject: [PATCH 0 of 7] - Improve handling remotes, origin, and submodules
Date: Sun,  3 Feb 2008 12:20:42 -0500	[thread overview]
Message-ID: <1202059249-3532-1-git-send-email-mlevedahl@gmail.com> (raw)

This patch series was inspired by several issues dealing with
multiple remotes and submodules. The tests added as the last
patch demonstrate the specific use pattern to be supported,
and that does not work currently.

1 - user A creates a project on server "frotz" with a submodule.
2 - user B clones the project, forks it, adds a submodule, and
publishes the fork on server "fork"

user A adds the fork to his working tree, via git remote add +
git fetch. The desire is that:
1 - git submodule init + git submodule update include the new
submdule added in the fork.
2 - The top-level project and all submodules use the same
remote nickname to refer to the same server.

Breakage in 1.5.4 without this patch series is in several places:

1 - git submodule does not follow the top-level project's
branch.<name>.remote in fetching, so does not try to clone
the new submodule from remoe "fork" where the fork exists.
2 - If 1 were fixed, git submodule still invokes clone without "-o
<remotenick>" when cloning, so each submodule would have "origin"
point to a different remote.
3 - If 2 were fixed, submodule update leaves submodules on detached
heads, so the remotes machinery cannot supply a remote name, and thus
"origin" is used for further updates. As origin may not be defined,
(e.g., for the submodule fetched from "fork" this also fails.)

The underlying design issue is the assumption that all projects
revolve around a single server, so that *the* server can be called
"origin" without confusion.  Given a project with multiple servers and
no one server being *the* server, origin cannot be usefully defined.
Absent submodules, the remotes machinery largely masks this: origin is
referred to only as the default remote and it is easy to avoid using
the default remote.  With submodules, this becomes more of an issue.

Following this patch series, the following is true:

1) The existing workflow of top-level and all sub-modules always
cloned from and interacting with a single default remote
nick-named "origin" is unchanged.
2) Via clone -o <nick> (or git confit core.origin <nick>), the
default remote is changed from origin to <nick>, and that default
is used instead of origin everywhere.
3) git-submodule uses the top-level's branch.<name>.remote to
choose which remote to fetch from, uses that in all submodules,
including defining that in existing submodules whose url is
relative (../* or ./*) indicating the submodule is maintained on
same server as top-level.

The penultimate patch addresses a basic usability issue, allowing
addition of a submodule in place in a project, rather than requiring
it be cloned from a remote.  This hole in the porcelain became evident
in creating a test (t7401) for this series.
submodules except by cloning).

             reply	other threads:[~2008-02-03 17:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03 17:20 Mark Levedahl [this message]
2008-02-03 17:20 ` [PATCH 1/7] Teach remote machinery about core.origin config variable Mark Levedahl
2008-02-03 17:20   ` [PATCH 2/7] git-remote - Unset core.origin when deleting the default remote Mark Levedahl
2008-02-03 17:20     ` [PATCH 3/7] git-clone - Set remotes.origin config variable Mark Levedahl
2008-02-03 17:20       ` [PATCH 4/7] git-submodule - Possibly inherit parent's default remote on init/clone Mark Levedahl
2008-02-03 17:20         ` [PATCH 5/7] Teach git-submodule to use top-level remote when updating subprojects Mark Levedahl
2008-02-03 17:20           ` [PATCH 6/7] git-submodule - Allow adding a submodule in-place Mark Levedahl
2008-02-03 17:20             ` [PATCH 7/7] Add t/t7401 - test submodule interaction with remotes machinery Mark Levedahl

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

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

  git send-email \
    --in-reply-to=1202059249-3532-1-git-send-email-mlevedahl@gmail.com \
    --to=mlevedahl@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.org \
    /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.
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 NNTP newsgroup(s).