git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0 of 7] - Improve handling remotes, origin, and submodules
@ 2008-02-03 17:20 Mark Levedahl
  2008-02-03 17:20 ` [PATCH 1/7] Teach remote machinery about core.origin config variable Mark Levedahl
  0 siblings, 1 reply; 9+ messages in thread
From: Mark Levedahl @ 2008-02-03 17:20 UTC (permalink / raw)
  To: gitster; +Cc: git

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

^ permalink raw reply	[flat|nested] 9+ messages in thread
* [PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules
@ 2008-02-03 17:31 Mark Levedahl
  2008-02-03 17:31 ` [PATCH 1/7] Teach remote machinery about core.origin config variable Mark Levedahl
  0 siblings, 1 reply; 9+ messages in thread
From: Mark Levedahl @ 2008-02-03 17:31 UTC (permalink / raw)
  To: gitster; +Cc: git

(sigh, someday I'll get this command line email addressing stuff
sorted out - resending as I mangled Junio's email)

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-02-03 17:32 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-03 17:20 [PATCH 0 of 7] - Improve handling remotes, origin, and submodules Mark Levedahl
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
  -- strict thread matches above, loose matches on Subject: below --
2008-02-03 17:31 [PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules Mark Levedahl
2008-02-03 17:31 ` [PATCH 1/7] Teach remote machinery about core.origin config variable Mark Levedahl
2008-02-03 17:31   ` [PATCH 2/7] git-remote - Unset core.origin when deleting the default remote Mark Levedahl
2008-02-03 17:31     ` [PATCH 3/7] git-clone - Set remotes.origin config variable Mark Levedahl
2008-02-03 17:31       ` [PATCH 4/7] git-submodule - Possibly inherit parent's default remote on init/clone Mark Levedahl
2008-02-03 17:31         ` [PATCH 5/7] Teach git-submodule to use top-level remote when updating subprojects Mark Levedahl

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