mirror of
https://github.com/git/git.git
synced 2024-11-09 02:33:11 +01:00
ec05df353c
This change makes "submodule add" much more strict in the arguments it takes, and is intended to address confusion as recently noted on the git-list. With this change, the required syntax is: $ git submodule add URL path Specifically, this eliminates the form $ git submodule add URL which was confused by more than one person as $ git submodule add path With this patch, the URL locating the submodule's origin repository can be either an absolute URL, or (if it begins with ./ or ../) can express the submodule's repository location relative to the superproject's origin. This patch also eliminates a third form of URL, which was relative to the superproject's top-level directory (not its repository). Any URL that was neither absolute nor matched ./*|../* was assumed to point to a subdirectory of the superproject as the location of the submodule's origin repository. This URL form was confusing and does not seem to correspond to an important use-case. Specifically, no-one has identified the need to clone from a repository already in the superproject's tree, but if this is needed it is easily done using an absolute URL: $(pwd)/relative-path. So, no functionality is lost with this patch. (t6008-rev-list-submodule.sh did rely upon this relative URL, fixed by using $(pwd).) Following this change, there are exactly four variants of submodule-add, as both arguments have two flavors: URL can be absolute, or can begin with ./|../ and thus names the submodule's origin relative to the superproject's origin. Note: With this patch, "submodule add" discerns an absolute URL as matching /*|*:*: e.g., URL begins with /, or it contains a :. This works for all valid URLs, an absolute path in POSIX, as well as an absolute path on Windows). path can either already exist as a valid git repo, or will be cloned from the given URL. The first form here eases creation of a new submodule in an existing superproject as the submodule can be added and tested in-tree before pushing to the public repository. However, the more usual form is the second, where the repo is cloned from the given URL. This specifically addresses the issue of $ git submodule add a/b/c attempting to clone from a repository at "a/b/c" to create a new module in "c". This also simplifies description of "relative URL" as there is now exactly *one* form: a URL relative to the parent's origin repo. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
42 lines
812 B
Bash
Executable file
42 lines
812 B
Bash
Executable file
#!/bin/sh
|
|
#
|
|
# Copyright (c) 2007 Johannes E. Schindelin
|
|
#
|
|
|
|
test_description='git rev-list involving submodules that this repo has'
|
|
|
|
. ./test-lib.sh
|
|
|
|
test_expect_success 'setup' '
|
|
: > file &&
|
|
git add file &&
|
|
test_tick &&
|
|
git commit -m initial &&
|
|
echo 1 > file &&
|
|
test_tick &&
|
|
git commit -m second file &&
|
|
echo 2 > file &&
|
|
test_tick &&
|
|
git commit -m third file &&
|
|
|
|
rm .git/index &&
|
|
|
|
: > super-file &&
|
|
git add super-file &&
|
|
git submodule add "$(pwd)" sub &&
|
|
git symbolic-ref HEAD refs/heads/super &&
|
|
test_tick &&
|
|
git commit -m super-initial &&
|
|
echo 1 > super-file &&
|
|
test_tick &&
|
|
git commit -m super-first super-file &&
|
|
echo 2 > super-file &&
|
|
test_tick &&
|
|
git commit -m super-second super-file
|
|
'
|
|
|
|
test_expect_success "Ilari's test" '
|
|
git rev-list --objects super master ^super^
|
|
'
|
|
|
|
test_done
|