[PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules

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

 



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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

  Powered by Linux