Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> I often use a local filesystem location for shared code I'm using in some
> personal projects, mainly because I want to avoid the hassle of setting
> up a server location for it (and the git test suite uses that feature too
> for similar reasons). That doesn't make much sense when working together
> with others, but that is not an issue in these use cases.
>
> So I see three different location types supported by current submodule
> add:
> 1) a URL reachable by you and your coworkers
> 2) a path relative to the URL of the superproject's default remote
> 3) A local filesystem location which can only be shared locally
> And each of them has its merits and uses (and using two of them everyday
> might make it easy to overlook the third ;-)
I suspect that it would be a relatively easy fix if your toplevel
superproject is its own authoritative upstream. Something along the line
of this patch, perhaps? It is obviously untested, and we may want to
issue an "echo >&2 'info:...'" to tell the user what we are assuming in
this codepath.
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index b010a67..6d27729 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -34,7 +34,7 @@ resolve_relative_url ()
{
remote=$(get_default_remote)
remoteurl=$(git config "remote.$remote.url") ||
- die "remote ($remote) does not have a url defined in .git/config"
+ remoteurl=$(pwd) # the repository is its own authoritative upstream
url="$1"
remoteurl=${remoteurl%/}
sep=/
--
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