2007-05-26 15:56:40 +02:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
2012-06-25 12:56:59 +02:00
|
|
|
# git-submodule.sh: add, init, update or list git submodules
|
2007-05-26 15:56:40 +02:00
|
|
|
#
|
|
|
|
# Copyright (c) 2007 Lars Hjemli
|
|
|
|
|
2009-08-19 03:45:19 +02:00
|
|
|
dashless=$(basename "$0" | sed -e 's/-/ /')
|
2012-11-21 22:25:42 +01:00
|
|
|
USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
|
2009-08-19 03:45:24 +02:00
|
|
|
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
|
2009-08-19 03:45:19 +02:00
|
|
|
or: $dashless [--quiet] init [--] [<path>...]
|
submodule update: add --remote for submodule's upstream changes
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 17:03:32 +01:00
|
|
|
or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
|
2009-08-28 01:59:25 +02:00
|
|
|
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
|
2009-08-19 03:45:22 +02:00
|
|
|
or: $dashless [--quiet] foreach [--recursive] <command>
|
2012-10-26 21:44:42 +02:00
|
|
|
or: $dashless [--quiet] sync [--recursive] [--] [<path>...]"
|
2007-11-06 10:50:02 +01:00
|
|
|
OPTIONS_SPEC=
|
2007-05-26 15:56:40 +02:00
|
|
|
. git-sh-setup
|
2011-05-21 20:43:58 +02:00
|
|
|
. git-sh-i18n
|
2008-08-24 20:46:10 +02:00
|
|
|
. git-parse-remote
|
2007-05-26 15:56:40 +02:00
|
|
|
require_work_tree
|
|
|
|
|
2008-01-15 11:48:45 +01:00
|
|
|
command=
|
2007-06-24 23:06:07 +02:00
|
|
|
branch=
|
2010-07-17 17:11:43 +02:00
|
|
|
force=
|
2009-05-04 21:30:01 +02:00
|
|
|
reference=
|
2007-05-26 15:56:40 +02:00
|
|
|
cached=
|
2010-04-26 11:50:39 +02:00
|
|
|
recursive=
|
|
|
|
init=
|
2009-08-13 21:32:50 +02:00
|
|
|
files=
|
submodule update: add --remote for submodule's upstream changes
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 17:03:32 +01:00
|
|
|
remote=
|
2009-02-05 23:18:32 +01:00
|
|
|
nofetch=
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
update=
|
2009-08-19 03:45:22 +02:00
|
|
|
prefix=
|
2012-09-30 01:05:58 +02:00
|
|
|
custom_name=
|
2007-05-26 15:56:40 +02:00
|
|
|
|
2012-06-06 13:57:29 +02:00
|
|
|
# The function takes at most 2 arguments. The first argument is the
|
|
|
|
# URL that navigates to the submodule origin repo. When relative, this URL
|
|
|
|
# is relative to the superproject origin URL repo. The second up_path
|
|
|
|
# argument, if specified, is the relative path that navigates
|
|
|
|
# from the submodule working tree to the superproject working tree.
|
|
|
|
#
|
|
|
|
# The output of the function is the origin URL of the submodule.
|
|
|
|
#
|
|
|
|
# The output will either be an absolute URL or filesystem path (if the
|
|
|
|
# superproject origin URL is an absolute URL or filesystem path,
|
|
|
|
# respectively) or a relative file system path (if the superproject
|
|
|
|
# origin URL is a relative file system path).
|
|
|
|
#
|
|
|
|
# When the output is a relative file system path, the path is either
|
|
|
|
# relative to the submodule working tree, if up_path is specified, or to
|
|
|
|
# the superproject working tree otherwise.
|
2007-09-24 04:19:42 +02:00
|
|
|
resolve_relative_url ()
|
|
|
|
{
|
2008-08-24 20:46:10 +02:00
|
|
|
remote=$(get_default_remote)
|
2008-06-14 19:09:41 +02:00
|
|
|
remoteurl=$(git config "remote.$remote.url") ||
|
2011-06-06 21:58:04 +02:00
|
|
|
remoteurl=$(pwd) # the repository is its own authoritative upstream
|
2007-09-24 04:19:42 +02:00
|
|
|
url="$1"
|
git-submodule.sh - Remove trailing / from URL if found
git clone does not complain if a trailing '/' is included in the origin
URL, but doing so causes resolution of a submodule's URL relative to the
superproject to fail. Trailing /'s are likely when cloning locally using
tab-completion, so the slash may appear in either superproject or
submodule URL. So, ignore the trailing slash if it already exists in
the superproject's URL, and don't record one for the submodule (which
could itself have submodules...).
The problem I'm trying to fix is that a number of folks have
superprojects checked out where the recorded origin URL has a trailing
/, and a submodule has its origin in a directory sitting right next to
the superproject on the server. Thus, we have:
superproject url = server:/public/super
submodoule url = server:/public/sub1
However, in the checked out superproject's .git/config
[remote "origin"]
url = server:/public/super/
and for similar reasons, the submodule has its URL recorded in .gitmodules as
[submodule "sub"]
path = submodule1
url = ../sub1/
resolve_relative_url gets the submodule's recorded url as $1, which
the caller retrieved from .gitmodules, and retrieves the superprojects
origin from .git/config. So in this case resolve_relative_url has
that:
url = ../sub1/
remoteurl = server:/public/super/
So, without any patch, resolve_relative_url computes the submodule's URL as:
server:/public/super/sub1/
rather than
server:/public/sub1
In summary, it is essential that resolve_relative_url strip the
trailing / from the superproject's url before starting, and
beneficial if it assures that the result does not contain
a trailing / as the submodule may itself also be a superproject.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22 01:54:01 +02:00
|
|
|
remoteurl=${remoteurl%/}
|
2011-01-10 11:37:26 +01:00
|
|
|
sep=/
|
2012-06-06 13:57:29 +02:00
|
|
|
up_path="$2"
|
|
|
|
|
|
|
|
case "$remoteurl" in
|
|
|
|
*:*|/*)
|
|
|
|
is_relative=
|
|
|
|
;;
|
2012-06-06 13:57:30 +02:00
|
|
|
./*|../*)
|
|
|
|
is_relative=t
|
|
|
|
;;
|
2012-06-06 13:57:29 +02:00
|
|
|
*)
|
|
|
|
is_relative=t
|
2012-06-06 13:57:30 +02:00
|
|
|
remoteurl="./$remoteurl"
|
2012-06-06 13:57:29 +02:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2007-09-24 04:19:42 +02:00
|
|
|
while test -n "$url"
|
|
|
|
do
|
|
|
|
case "$url" in
|
|
|
|
../*)
|
|
|
|
url="${url#../}"
|
2011-01-10 11:37:26 +01:00
|
|
|
case "$remoteurl" in
|
|
|
|
*/*)
|
|
|
|
remoteurl="${remoteurl%/*}"
|
|
|
|
;;
|
|
|
|
*:*)
|
|
|
|
remoteurl="${remoteurl%:*}"
|
|
|
|
sep=:
|
|
|
|
;;
|
|
|
|
*)
|
2012-06-06 13:57:30 +02:00
|
|
|
if test -z "$is_relative" || test "." = "$remoteurl"
|
|
|
|
then
|
|
|
|
die "$(eval_gettext "cannot strip one component off url '\$remoteurl'")"
|
|
|
|
else
|
|
|
|
remoteurl=.
|
|
|
|
fi
|
2011-01-10 11:37:26 +01:00
|
|
|
;;
|
|
|
|
esac
|
2007-09-24 04:19:42 +02:00
|
|
|
;;
|
|
|
|
./*)
|
|
|
|
url="${url#./}"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break;;
|
|
|
|
esac
|
|
|
|
done
|
2012-06-06 13:57:30 +02:00
|
|
|
remoteurl="$remoteurl$sep${url%/}"
|
|
|
|
echo "${is_relative:+${up_path}}${remoteurl#./}"
|
2007-09-24 04:19:42 +02:00
|
|
|
}
|
|
|
|
|
2008-08-22 09:30:50 +02:00
|
|
|
#
|
|
|
|
# Get submodule info for registered submodules
|
|
|
|
# $@ = path to limit submodule list
|
|
|
|
#
|
|
|
|
module_list()
|
|
|
|
{
|
2012-08-14 22:35:27 +02:00
|
|
|
(
|
|
|
|
git ls-files --error-unmatch --stage -- "$@" ||
|
|
|
|
echo "unmatched pathspec exists"
|
|
|
|
) |
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
perl -e '
|
|
|
|
my %unmerged = ();
|
|
|
|
my ($null_sha1) = ("0" x 40);
|
2012-08-14 22:35:27 +02:00
|
|
|
my @out = ();
|
|
|
|
my $unmatched = 0;
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
while (<STDIN>) {
|
2012-08-14 22:35:27 +02:00
|
|
|
if (/^unmatched pathspec/) {
|
|
|
|
$unmatched = 1;
|
|
|
|
next;
|
|
|
|
}
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
chomp;
|
|
|
|
my ($mode, $sha1, $stage, $path) =
|
|
|
|
/^([0-7]+) ([0-9a-f]{40}) ([0-3])\t(.*)$/;
|
|
|
|
next unless $mode eq "160000";
|
|
|
|
if ($stage ne "0") {
|
|
|
|
if (!$unmerged{$path}++) {
|
2012-08-14 22:35:27 +02:00
|
|
|
push @out, "$mode $null_sha1 U\t$path\n";
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
}
|
|
|
|
next;
|
|
|
|
}
|
2012-08-14 22:35:27 +02:00
|
|
|
push @out, "$_\n";
|
|
|
|
}
|
|
|
|
if ($unmatched) {
|
|
|
|
print "#unmatched\n";
|
|
|
|
} else {
|
|
|
|
print for (@out);
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
}
|
|
|
|
'
|
2008-08-22 09:30:50 +02:00
|
|
|
}
|
|
|
|
|
2012-08-14 22:35:27 +02:00
|
|
|
die_if_unmatched ()
|
|
|
|
{
|
|
|
|
if test "$1" = "#unmatched"
|
|
|
|
then
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2012-12-11 19:58:15 +01:00
|
|
|
#
|
|
|
|
# Print a submodule configuration setting
|
|
|
|
#
|
|
|
|
# $1 = submodule name
|
|
|
|
# $2 = option name
|
|
|
|
# $3 = default value
|
|
|
|
#
|
|
|
|
# Checks in the usual git-config places first (for overrides),
|
|
|
|
# otherwise it falls back on .gitmodules. This allows you to
|
|
|
|
# distribute project-wide defaults in .gitmodules, while still
|
|
|
|
# customizing individual repositories if necessary. If the option is
|
|
|
|
# not in .gitmodules either, print a default value.
|
|
|
|
#
|
|
|
|
get_submodule_config () {
|
|
|
|
name="$1"
|
|
|
|
option="$2"
|
|
|
|
default="$3"
|
|
|
|
value=$(git config submodule."$name"."$option")
|
|
|
|
if test -z "$value"
|
|
|
|
then
|
|
|
|
value=$(git config -f .gitmodules submodule."$name"."$option")
|
|
|
|
fi
|
|
|
|
printf '%s' "${value:-$default}"
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-06-11 21:12:24 +02:00
|
|
|
#
|
|
|
|
# Map submodule path to submodule name
|
|
|
|
#
|
|
|
|
# $1 = path
|
|
|
|
#
|
|
|
|
module_name()
|
|
|
|
{
|
2007-07-26 00:51:26 +02:00
|
|
|
# Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
sm_path="$1"
|
2008-06-11 15:09:19 +02:00
|
|
|
re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
|
2008-05-15 09:42:58 +02:00
|
|
|
name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' |
|
2007-07-26 00:51:26 +02:00
|
|
|
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
|
2011-10-21 15:49:35 +02:00
|
|
|
test -z "$name" &&
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$sm_path'")"
|
2011-10-21 15:49:35 +02:00
|
|
|
echo "$name"
|
2007-06-11 21:12:24 +02:00
|
|
|
}
|
2007-06-06 11:13:01 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Clone a submodule
|
|
|
|
#
|
2008-01-15 11:35:49 +01:00
|
|
|
# Prior to calling, cmd_update checks that a possibly existing
|
2007-06-24 23:06:07 +02:00
|
|
|
# path is not a git repository.
|
2008-01-15 11:35:49 +01:00
|
|
|
# Likewise, cmd_add checks that path does not exist at all,
|
2007-06-24 23:06:07 +02:00
|
|
|
# since it is the location of a new submodule.
|
|
|
|
#
|
2007-06-06 11:13:01 +02:00
|
|
|
module_clone()
|
|
|
|
{
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
sm_path=$1
|
2012-09-30 01:05:58 +02:00
|
|
|
name=$2
|
|
|
|
url=$3
|
|
|
|
reference="$4"
|
2011-07-26 23:39:03 +02:00
|
|
|
quiet=
|
|
|
|
if test -n "$GIT_QUIET"
|
|
|
|
then
|
|
|
|
quiet=-q
|
|
|
|
fi
|
2007-06-06 11:13:01 +02:00
|
|
|
|
2011-08-15 23:17:47 +02:00
|
|
|
gitdir=
|
|
|
|
gitdir_base=
|
2012-03-04 22:15:36 +01:00
|
|
|
base_name=$(dirname "$name")
|
2007-06-06 11:13:01 +02:00
|
|
|
|
2011-08-15 23:17:47 +02:00
|
|
|
gitdir=$(git rev-parse --git-dir)
|
2012-03-04 22:15:36 +01:00
|
|
|
gitdir_base="$gitdir/modules/$base_name"
|
|
|
|
gitdir="$gitdir/modules/$name"
|
2011-08-15 23:17:47 +02:00
|
|
|
|
|
|
|
if test -d "$gitdir"
|
2009-05-04 21:30:01 +02:00
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
mkdir -p "$sm_path"
|
2011-08-15 23:17:47 +02:00
|
|
|
rm -f "$gitdir/index"
|
2009-05-04 21:30:01 +02:00
|
|
|
else
|
2011-08-15 23:17:47 +02:00
|
|
|
mkdir -p "$gitdir_base"
|
2012-07-22 16:49:44 +02:00
|
|
|
(
|
|
|
|
clear_local_git_env
|
|
|
|
git clone $quiet -n ${reference:+"$reference"} \
|
|
|
|
--separate-git-dir "$gitdir" "$url" "$sm_path"
|
|
|
|
) ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Clone of '\$url' into submodule path '\$sm_path' failed")"
|
2011-08-15 23:17:47 +02:00
|
|
|
fi
|
2012-03-04 22:14:30 +01:00
|
|
|
|
2012-07-12 19:45:32 +02:00
|
|
|
# We already are at the root of the work tree but cd_to_toplevel will
|
|
|
|
# resolve any symlinks that might be present in $PWD
|
|
|
|
a=$(cd_to_toplevel && cd "$gitdir" && pwd)/
|
2012-07-22 21:55:47 +02:00
|
|
|
b=$(cd_to_toplevel && cd "$sm_path" && pwd)/
|
2012-03-04 22:16:19 +01:00
|
|
|
# normalize Windows-style absolute paths to POSIX-style absolute paths
|
|
|
|
case $a in [a-zA-Z]:/*) a=/${a%%:*}${a#*:} ;; esac
|
|
|
|
case $b in [a-zA-Z]:/*) b=/${b%%:*}${b#*:} ;; esac
|
2012-03-04 22:15:08 +01:00
|
|
|
# Remove all common leading directories after a sanity check
|
|
|
|
if test "${a#$b}" != "$a" || test "${b#$a}" != "$b"; then
|
|
|
|
die "$(eval_gettext "Gitdir '\$a' is part of the submodule path '\$b' or vice versa")"
|
|
|
|
fi
|
|
|
|
while test "${a%%/*}" = "${b%%/*}"
|
|
|
|
do
|
|
|
|
a=${a#*/}
|
|
|
|
b=${b#*/}
|
|
|
|
done
|
|
|
|
# Now chop off the trailing '/'s that were added in the beginning
|
|
|
|
a=${a%/}
|
|
|
|
b=${b%/}
|
|
|
|
|
2012-04-09 22:08:02 +02:00
|
|
|
# Turn each leading "*/" component into "../"
|
|
|
|
rel=$(echo $b | sed -e 's|[^/][^/]*|..|g')
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
echo "gitdir: $rel/$a" >"$sm_path/.git"
|
2012-03-04 22:15:36 +01:00
|
|
|
|
2012-04-09 22:08:02 +02:00
|
|
|
rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
(clear_local_git_env; cd "$sm_path" && GIT_WORK_TREE=. git config core.worktree "$rel/$b")
|
2007-06-06 11:13:01 +02:00
|
|
|
}
|
|
|
|
|
2007-06-24 23:06:07 +02:00
|
|
|
#
|
|
|
|
# Add a new submodule to the working tree, .gitmodules and the index
|
|
|
|
#
|
git-submodule - make "submodule add" more strict, and document it
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>
2008-07-10 03:05:40 +02:00
|
|
|
# $@ = repo path
|
2007-06-24 23:06:07 +02:00
|
|
|
#
|
|
|
|
# optional branch is stored in global branch variable
|
|
|
|
#
|
2008-01-15 11:35:49 +01:00
|
|
|
cmd_add()
|
2007-06-24 23:06:07 +02:00
|
|
|
{
|
2008-01-15 11:48:45 +01:00
|
|
|
# parse $args after "submodule ... add".
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-b | --branch)
|
|
|
|
case "$2" in '') usage ;; esac
|
|
|
|
branch=$2
|
|
|
|
shift
|
|
|
|
;;
|
2010-07-17 17:11:43 +02:00
|
|
|
-f | --force)
|
|
|
|
force=$1
|
|
|
|
;;
|
2008-01-15 11:48:45 +01:00
|
|
|
-q|--quiet)
|
2009-06-17 00:33:00 +02:00
|
|
|
GIT_QUIET=1
|
2008-01-15 11:48:45 +01:00
|
|
|
;;
|
2009-05-04 21:30:01 +02:00
|
|
|
--reference)
|
|
|
|
case "$2" in '') usage ;; esac
|
|
|
|
reference="--reference=$2"
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
--reference=*)
|
|
|
|
reference="$1"
|
|
|
|
;;
|
2012-09-30 01:05:58 +02:00
|
|
|
--name)
|
|
|
|
case "$2" in '') usage ;; esac
|
|
|
|
custom_name=$2
|
|
|
|
shift
|
|
|
|
;;
|
2008-01-15 11:48:45 +01:00
|
|
|
--)
|
|
|
|
shift
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
2007-06-24 23:06:07 +02:00
|
|
|
repo=$1
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
sm_path=$2
|
2007-06-24 23:06:07 +02:00
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -z "$sm_path"; then
|
|
|
|
sm_path=$(echo "$repo" |
|
2009-09-22 17:10:12 +02:00
|
|
|
sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
|
|
|
|
fi
|
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -z "$repo" -o -z "$sm_path"; then
|
2007-06-24 23:06:07 +02:00
|
|
|
usage
|
|
|
|
fi
|
|
|
|
|
git-submodule - make "submodule add" more strict, and document it
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>
2008-07-10 03:05:40 +02:00
|
|
|
# assure repo is absolute or relative to parent
|
|
|
|
case "$repo" in
|
|
|
|
./*|../*)
|
|
|
|
# dereference source url relative to parent's url
|
|
|
|
realrepo=$(resolve_relative_url "$repo") || exit
|
|
|
|
;;
|
|
|
|
*:*|/*)
|
|
|
|
# absolute url
|
|
|
|
realrepo=$repo
|
|
|
|
;;
|
|
|
|
*)
|
2011-05-21 20:44:01 +02:00
|
|
|
die "$(eval_gettext "repo URL: '\$repo' must be absolute or begin with ./|../")"
|
git-submodule - make "submodule add" more strict, and document it
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>
2008-07-10 03:05:40 +02:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2009-03-03 16:08:21 +01:00
|
|
|
# normalize path:
|
|
|
|
# multiple //; leading ./; /./; /../; trailing /
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
sm_path=$(printf '%s/\n' "$sm_path" |
|
2009-03-03 16:08:21 +01:00
|
|
|
sed -e '
|
|
|
|
s|//*|/|g
|
|
|
|
s|^\(\./\)*||
|
|
|
|
s|/\./|/|g
|
|
|
|
:start
|
|
|
|
s|\([^/]*\)/\.\./||
|
|
|
|
tstart
|
|
|
|
s|/*$||
|
|
|
|
')
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
|
|
|
|
die "$(eval_gettext "'\$sm_path' already exists in the index")"
|
2007-06-24 23:06:07 +02:00
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path" > /dev/null 2>&1
|
2010-07-17 17:11:43 +02:00
|
|
|
then
|
2011-08-07 13:58:17 +02:00
|
|
|
eval_gettextln "The following path is ignored by one of your .gitignore files:
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
\$sm_path
|
2011-08-07 13:58:17 +02:00
|
|
|
Use -f if you really want to add it." >&2
|
2010-07-17 17:11:43 +02:00
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2012-09-30 01:05:58 +02:00
|
|
|
if test -n "$custom_name"
|
|
|
|
then
|
|
|
|
sm_name="$custom_name"
|
|
|
|
else
|
|
|
|
sm_name="$sm_path"
|
|
|
|
fi
|
|
|
|
|
2008-03-05 02:15:02 +01:00
|
|
|
# perhaps the path exists and is already a git repo, else clone it
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -e "$sm_path"
|
2008-03-05 02:15:02 +01:00
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -d "$sm_path"/.git -o -f "$sm_path"/.git
|
2008-03-05 02:15:02 +01:00
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
eval_gettextln "Adding existing repo at '\$sm_path' to the index"
|
2008-03-05 02:15:02 +01:00
|
|
|
else
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "'\$sm_path' already exists and is not a valid git repo")"
|
2008-03-05 02:15:02 +01:00
|
|
|
fi
|
2008-07-10 03:05:41 +02:00
|
|
|
|
2008-03-05 02:15:02 +01:00
|
|
|
else
|
2012-09-30 23:01:29 +02:00
|
|
|
if test -d ".git/modules/$sm_name"
|
|
|
|
then
|
|
|
|
if test -z "$force"
|
|
|
|
then
|
|
|
|
echo >&2 "$(eval_gettext "A git directory for '\$sm_name' is found locally with remote(s):")"
|
|
|
|
GIT_DIR=".git/modules/$sm_name" GIT_WORK_TREE=. git remote -v | grep '(fetch)' | sed -e s,^," ", -e s,' (fetch)',, >&2
|
|
|
|
echo >&2 "$(eval_gettext "If you want to reuse this local git directory instead of cloning again from")"
|
|
|
|
echo >&2 " $realrepo"
|
|
|
|
echo >&2 "$(eval_gettext "use the '--force' option. If the local git directory is not the correct repo")"
|
|
|
|
die "$(eval_gettext "or you are unsure what this means choose another name with the '--name' option.")"
|
|
|
|
else
|
|
|
|
echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
|
|
|
|
fi
|
|
|
|
fi
|
2012-09-30 01:05:58 +02:00
|
|
|
module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" || exit
|
2009-04-19 05:42:07 +02:00
|
|
|
(
|
2010-02-25 00:34:17 +01:00
|
|
|
clear_local_git_env
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
cd "$sm_path" &&
|
2009-04-19 05:42:07 +02:00
|
|
|
# ash fails to wordsplit ${branch:+-b "$branch"...}
|
|
|
|
case "$branch" in
|
|
|
|
'') git checkout -f -q ;;
|
2010-12-01 19:50:46 +01:00
|
|
|
?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
|
2009-04-19 05:42:07 +02:00
|
|
|
esac
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
|
2008-03-05 02:15:02 +01:00
|
|
|
fi
|
2012-09-30 01:05:58 +02:00
|
|
|
git config submodule."$sm_name".url "$realrepo"
|
2008-03-05 02:15:02 +01:00
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
git add $force "$sm_path" ||
|
|
|
|
die "$(eval_gettext "Failed to add submodule '\$sm_path'")"
|
2007-06-24 23:06:07 +02:00
|
|
|
|
2012-09-30 01:05:58 +02:00
|
|
|
git config -f .gitmodules submodule."$sm_name".path "$sm_path" &&
|
|
|
|
git config -f .gitmodules submodule."$sm_name".url "$repo" &&
|
2012-12-19 17:03:33 +01:00
|
|
|
if test -n "$branch"
|
|
|
|
then
|
|
|
|
git config -f .gitmodules submodule."$sm_name".branch "$branch"
|
|
|
|
fi &&
|
2010-07-05 19:33:03 +02:00
|
|
|
git add --force .gitmodules ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
|
2007-06-24 23:06:07 +02:00
|
|
|
}
|
|
|
|
|
2008-08-11 01:10:04 +02:00
|
|
|
#
|
|
|
|
# Execute an arbitrary command sequence in each checked out
|
|
|
|
# submodule
|
|
|
|
#
|
|
|
|
# $@ = command to execute
|
|
|
|
#
|
|
|
|
cmd_foreach()
|
|
|
|
{
|
2009-08-19 03:45:19 +02:00
|
|
|
# parse $args after "submodule ... foreach".
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-q|--quiet)
|
|
|
|
GIT_QUIET=1
|
|
|
|
;;
|
2009-08-19 03:45:22 +02:00
|
|
|
--recursive)
|
|
|
|
recursive=1
|
|
|
|
;;
|
2009-08-19 03:45:19 +02:00
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
2010-05-21 18:10:10 +02:00
|
|
|
toplevel=$(pwd)
|
|
|
|
|
2011-06-30 02:34:58 +02:00
|
|
|
# dup stdin so that it can be restored when running the external
|
|
|
|
# command in the subshell (and a recursive call to this function)
|
|
|
|
exec 3<&0
|
|
|
|
|
2008-08-22 09:30:50 +02:00
|
|
|
module_list |
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
while read mode sha1 stage sm_path
|
2008-08-11 01:10:04 +02:00
|
|
|
do
|
2012-08-14 22:35:27 +02:00
|
|
|
die_if_unmatched "$mode"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -e "$sm_path"/.git
|
2008-08-11 01:10:04 +02:00
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
say "$(eval_gettext "Entering '\$prefix\$sm_path'")"
|
|
|
|
name=$(module_name "$sm_path")
|
2009-08-19 03:45:22 +02:00
|
|
|
(
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
prefix="$prefix$sm_path/"
|
2010-02-25 00:34:17 +01:00
|
|
|
clear_local_git_env
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
# we make $path available to scripts ...
|
|
|
|
path=$sm_path
|
|
|
|
cd "$sm_path" &&
|
2009-08-19 03:45:22 +02:00
|
|
|
eval "$@" &&
|
|
|
|
if test -n "$recursive"
|
|
|
|
then
|
|
|
|
cmd_foreach "--recursive" "$@"
|
|
|
|
fi
|
2011-06-30 02:34:58 +02:00
|
|
|
) <&3 3<&- ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Stopping at '\$sm_path'; script returned non-zero status.")"
|
2008-08-11 01:10:04 +02:00
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2007-05-26 15:56:40 +02:00
|
|
|
#
|
2007-06-06 11:13:02 +02:00
|
|
|
# Register submodules in .git/config
|
2007-05-26 15:56:40 +02:00
|
|
|
#
|
|
|
|
# $@ = requested paths (default to all)
|
|
|
|
#
|
2008-01-15 11:35:49 +01:00
|
|
|
cmd_init()
|
2007-05-26 15:56:40 +02:00
|
|
|
{
|
2008-01-15 11:48:45 +01:00
|
|
|
# parse $args after "submodule ... init".
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-q|--quiet)
|
2009-06-17 00:33:00 +02:00
|
|
|
GIT_QUIET=1
|
2008-01-15 11:48:45 +01:00
|
|
|
;;
|
|
|
|
--)
|
|
|
|
shift
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
2008-08-22 09:30:50 +02:00
|
|
|
module_list "$@" |
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
while read mode sha1 stage sm_path
|
2007-05-26 15:56:40 +02:00
|
|
|
do
|
2012-08-14 22:35:27 +02:00
|
|
|
die_if_unmatched "$mode"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
name=$(module_name "$sm_path") || exit
|
2012-05-28 21:46:58 +02:00
|
|
|
|
|
|
|
# Copy url setting when it is not set yet
|
2011-06-26 01:26:02 +02:00
|
|
|
if test -z "$(git config "submodule.$name.url")"
|
|
|
|
then
|
|
|
|
url=$(git config -f .gitmodules submodule."$name".url)
|
|
|
|
test -z "$url" &&
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "No url found for submodule path '\$sm_path' in .gitmodules")"
|
2011-06-26 01:26:02 +02:00
|
|
|
|
|
|
|
# Possibly a url relative to parent
|
|
|
|
case "$url" in
|
|
|
|
./*|../*)
|
|
|
|
url=$(resolve_relative_url "$url") || exit
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
git config submodule."$name".url "$url" ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Failed to register url for submodule path '\$sm_path'")"
|
2012-05-28 21:46:58 +02:00
|
|
|
|
|
|
|
say "$(eval_gettext "Submodule '\$name' (\$url) registered for path '\$sm_path'")"
|
2011-06-26 01:26:02 +02:00
|
|
|
fi
|
2007-05-26 15:56:40 +02:00
|
|
|
|
2011-06-26 01:26:02 +02:00
|
|
|
# Copy "update" setting when it is not set yet
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
upd="$(git config -f .gitmodules submodule."$name".update)"
|
|
|
|
test -z "$upd" ||
|
2011-06-26 01:26:02 +02:00
|
|
|
test -n "$(git config submodule."$name".update)" ||
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
git config submodule."$name".update "$upd" ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Failed to register update mode for submodule path '\$sm_path'")"
|
2007-05-26 15:56:40 +02:00
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
#
|
2007-06-06 11:13:02 +02:00
|
|
|
# Update each submodule path to correct revision, using clone and checkout as needed
|
2007-05-26 15:56:40 +02:00
|
|
|
#
|
|
|
|
# $@ = requested paths (default to all)
|
|
|
|
#
|
2008-01-15 11:35:49 +01:00
|
|
|
cmd_update()
|
2007-05-26 15:56:40 +02:00
|
|
|
{
|
2008-01-15 11:48:45 +01:00
|
|
|
# parse $args after "submodule ... update".
|
2010-11-03 07:26:25 +01:00
|
|
|
orig_flags=
|
2008-01-15 11:48:45 +01:00
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-q|--quiet)
|
2009-06-17 00:33:00 +02:00
|
|
|
GIT_QUIET=1
|
2008-01-15 11:48:45 +01:00
|
|
|
;;
|
2008-05-16 12:23:03 +02:00
|
|
|
-i|--init)
|
2009-05-04 21:30:01 +02:00
|
|
|
init=1
|
2008-05-16 12:23:03 +02:00
|
|
|
;;
|
submodule update: add --remote for submodule's upstream changes
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 17:03:32 +01:00
|
|
|
--remote)
|
|
|
|
remote=1
|
|
|
|
;;
|
2009-02-05 23:18:32 +01:00
|
|
|
-N|--no-fetch)
|
|
|
|
nofetch=1
|
|
|
|
;;
|
2011-04-01 11:42:03 +02:00
|
|
|
-f|--force)
|
|
|
|
force=$1
|
|
|
|
;;
|
2009-04-24 01:06:38 +02:00
|
|
|
-r|--rebase)
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
update="rebase"
|
2009-04-24 01:06:38 +02:00
|
|
|
;;
|
2009-05-04 21:30:01 +02:00
|
|
|
--reference)
|
|
|
|
case "$2" in '') usage ;; esac
|
|
|
|
reference="--reference=$2"
|
2010-11-03 07:26:25 +01:00
|
|
|
orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
|
|
|
|
shift
|
2009-05-04 21:30:01 +02:00
|
|
|
;;
|
|
|
|
--reference=*)
|
|
|
|
reference="$1"
|
|
|
|
;;
|
2009-06-03 00:59:12 +02:00
|
|
|
-m|--merge)
|
|
|
|
update="merge"
|
|
|
|
;;
|
2009-08-19 03:45:23 +02:00
|
|
|
--recursive)
|
|
|
|
recursive=1
|
|
|
|
;;
|
2011-10-11 00:56:16 +02:00
|
|
|
--checkout)
|
|
|
|
update="checkout"
|
|
|
|
;;
|
2008-01-15 11:48:45 +01:00
|
|
|
--)
|
|
|
|
shift
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
2010-11-03 07:26:25 +01:00
|
|
|
orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
|
|
|
|
shift
|
2008-01-15 11:48:45 +01:00
|
|
|
done
|
|
|
|
|
2009-05-04 21:30:01 +02:00
|
|
|
if test -n "$init"
|
|
|
|
then
|
|
|
|
cmd_init "--" "$@" || return
|
|
|
|
fi
|
|
|
|
|
2011-02-17 17:18:45 +01:00
|
|
|
cloned_modules=
|
2011-06-13 19:15:26 +02:00
|
|
|
module_list "$@" | {
|
|
|
|
err=
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
while read mode sha1 stage sm_path
|
2007-05-26 15:56:40 +02:00
|
|
|
do
|
2012-08-14 22:35:27 +02:00
|
|
|
die_if_unmatched "$mode"
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
if test "$stage" = U
|
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
echo >&2 "Skipping unmerged submodule $sm_path"
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
continue
|
|
|
|
fi
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
name=$(module_name "$sm_path") || exit
|
2007-07-03 07:52:14 +02:00
|
|
|
url=$(git config submodule."$name".url)
|
submodule update: add --remote for submodule's upstream changes
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 17:03:32 +01:00
|
|
|
branch=$(get_submodule_config "$name" branch master)
|
2011-10-11 00:56:16 +02:00
|
|
|
if ! test -z "$update"
|
|
|
|
then
|
|
|
|
update_module=$update
|
|
|
|
else
|
|
|
|
update_module=$(git config submodule."$name".update)
|
|
|
|
fi
|
|
|
|
|
|
|
|
if test "$update_module" = "none"
|
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
echo "Skipping submodule '$sm_path'"
|
2011-10-11 00:56:16 +02:00
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
2007-06-06 11:13:02 +02:00
|
|
|
if test -z "$url"
|
2007-05-26 15:56:40 +02:00
|
|
|
then
|
|
|
|
# Only mention uninitialized submodules when its
|
|
|
|
# path have been specified
|
|
|
|
test "$#" != "0" &&
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
say "$(eval_gettext "Submodule path '\$sm_path' not initialized
|
2011-05-21 20:44:08 +02:00
|
|
|
Maybe you want to use 'update --init'?")"
|
2007-06-06 11:13:02 +02:00
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
|
2007-06-06 11:13:02 +02:00
|
|
|
then
|
2012-09-30 01:05:58 +02:00
|
|
|
module_clone "$sm_path" "$name" "$url" "$reference" || exit
|
2011-02-17 17:18:45 +01:00
|
|
|
cloned_modules="$cloned_modules;$name"
|
2007-06-11 21:12:22 +02:00
|
|
|
subsha1=
|
|
|
|
else
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
subsha1=$(clear_local_git_env; cd "$sm_path" &&
|
2007-07-03 07:52:14 +02:00
|
|
|
git rev-parse --verify HEAD) ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
|
2007-05-26 15:56:40 +02:00
|
|
|
fi
|
2007-06-06 11:13:02 +02:00
|
|
|
|
submodule update: add --remote for submodule's upstream changes
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 17:03:32 +01:00
|
|
|
if test -n "$remote"
|
|
|
|
then
|
|
|
|
if test -z "$nofetch"
|
|
|
|
then
|
|
|
|
# Fetch remote before determining tracking $sha1
|
|
|
|
(clear_local_git_env; cd "$sm_path" && git-fetch) ||
|
|
|
|
die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
|
|
|
|
fi
|
|
|
|
remote_name=$(clear_local_git_env; cd "$sm_path" && get_default_remote)
|
|
|
|
sha1=$(clear_local_git_env; cd "$sm_path" &&
|
|
|
|
git rev-parse --verify "${remote_name}/${branch}") ||
|
|
|
|
die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
|
|
|
|
fi
|
|
|
|
|
2012-07-25 19:41:54 +02:00
|
|
|
if test "$subsha1" != "$sha1" -o -n "$force"
|
2007-05-26 15:56:40 +02:00
|
|
|
then
|
2011-04-01 11:42:03 +02:00
|
|
|
subforce=$force
|
|
|
|
# If we don't already have a -f flag and the submodule has never been checked out
|
|
|
|
if test -z "$subsha1" -a -z "$force"
|
2008-09-26 17:33:23 +02:00
|
|
|
then
|
2011-04-01 11:42:03 +02:00
|
|
|
subforce="-f"
|
2008-09-26 17:33:23 +02:00
|
|
|
fi
|
2009-02-05 23:18:32 +01:00
|
|
|
|
|
|
|
if test -z "$nofetch"
|
|
|
|
then
|
2011-03-06 23:13:36 +01:00
|
|
|
# Run fetch only if $sha1 isn't present or it
|
|
|
|
# is not reachable from a ref.
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
(clear_local_git_env; cd "$sm_path" &&
|
2011-05-26 22:52:04 +02:00
|
|
|
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
|
2011-03-06 23:13:36 +01:00
|
|
|
test -z "$rev") || git-fetch)) ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
|
2009-02-05 23:18:32 +01:00
|
|
|
fi
|
|
|
|
|
2011-02-17 17:18:45 +01:00
|
|
|
# Is this something we just cloned?
|
|
|
|
case ";$cloned_modules;" in
|
|
|
|
*";$name;"*)
|
|
|
|
# then there is no local change to integrate
|
|
|
|
update_module= ;;
|
|
|
|
esac
|
|
|
|
|
2011-06-13 21:17:52 +02:00
|
|
|
must_die_on_failure=
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
case "$update_module" in
|
|
|
|
rebase)
|
|
|
|
command="git rebase"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
|
|
|
|
say_msg="$(eval_gettext "Submodule path '\$sm_path': rebased into '\$sha1'")"
|
2011-06-13 21:17:52 +02:00
|
|
|
must_die_on_failure=yes
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
;;
|
2009-06-03 00:59:12 +02:00
|
|
|
merge)
|
|
|
|
command="git merge"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die_msg="$(eval_gettext "Unable to merge '\$sha1' in submodule path '\$sm_path'")"
|
|
|
|
say_msg="$(eval_gettext "Submodule path '\$sm_path': merged in '\$sha1'")"
|
2011-06-13 21:17:52 +02:00
|
|
|
must_die_on_failure=yes
|
2009-06-03 00:59:12 +02:00
|
|
|
;;
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
*)
|
2011-04-01 11:42:03 +02:00
|
|
|
command="git checkout $subforce -q"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die_msg="$(eval_gettext "Unable to checkout '\$sha1' in submodule path '\$sm_path'")"
|
|
|
|
say_msg="$(eval_gettext "Submodule path '\$sm_path': checked out '\$sha1'")"
|
Rename submodule.<name>.rebase to submodule.<name>.update
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 08:27:06 +02:00
|
|
|
;;
|
|
|
|
esac
|
2007-05-26 15:56:40 +02:00
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
|
2011-06-13 19:15:26 +02:00
|
|
|
then
|
2011-07-13 23:31:35 +02:00
|
|
|
say "$say_msg"
|
2011-06-13 21:17:52 +02:00
|
|
|
elif test -n "$must_die_on_failure"
|
|
|
|
then
|
2011-07-13 23:31:35 +02:00
|
|
|
die_with_status 2 "$die_msg"
|
2011-06-13 19:15:26 +02:00
|
|
|
else
|
2011-07-13 23:31:35 +02:00
|
|
|
err="${err};$die_msg"
|
2011-06-13 21:17:52 +02:00
|
|
|
continue
|
2011-06-13 19:15:26 +02:00
|
|
|
fi
|
2007-05-26 15:56:40 +02:00
|
|
|
fi
|
2009-08-19 03:45:23 +02:00
|
|
|
|
|
|
|
if test -n "$recursive"
|
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
(clear_local_git_env; cd "$sm_path" && eval cmd_update "$orig_flags")
|
2011-06-13 19:15:26 +02:00
|
|
|
res=$?
|
|
|
|
if test $res -gt 0
|
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die_msg="$(eval_gettext "Failed to recurse into submodule path '\$sm_path'")"
|
2011-06-13 19:15:26 +02:00
|
|
|
if test $res -eq 1
|
|
|
|
then
|
2011-07-13 23:31:35 +02:00
|
|
|
err="${err};$die_msg"
|
2011-06-13 19:15:26 +02:00
|
|
|
continue
|
|
|
|
else
|
2011-07-13 23:31:35 +02:00
|
|
|
die_with_status $res "$die_msg"
|
2011-06-13 19:15:26 +02:00
|
|
|
fi
|
|
|
|
fi
|
2009-08-19 03:45:23 +02:00
|
|
|
fi
|
2007-05-26 15:56:40 +02:00
|
|
|
done
|
2011-06-13 19:15:26 +02:00
|
|
|
|
|
|
|
if test -n "$err"
|
|
|
|
then
|
|
|
|
OIFS=$IFS
|
|
|
|
IFS=';'
|
|
|
|
for e in $err
|
|
|
|
do
|
|
|
|
if test -n "$e"
|
|
|
|
then
|
|
|
|
echo >&2 "$e"
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
IFS=$OIFS
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
}
|
2007-05-26 15:56:40 +02:00
|
|
|
}
|
|
|
|
|
2007-06-27 01:40:58 +02:00
|
|
|
set_name_rev () {
|
|
|
|
revname=$( (
|
2010-02-25 00:34:17 +01:00
|
|
|
clear_local_git_env
|
2007-06-27 01:40:58 +02:00
|
|
|
cd "$1" && {
|
2007-07-03 07:52:14 +02:00
|
|
|
git describe "$2" 2>/dev/null ||
|
|
|
|
git describe --tags "$2" 2>/dev/null ||
|
2008-04-15 04:48:06 +02:00
|
|
|
git describe --contains "$2" 2>/dev/null ||
|
|
|
|
git describe --all --always "$2"
|
2007-06-27 01:40:58 +02:00
|
|
|
}
|
|
|
|
) )
|
|
|
|
test -z "$revname" || revname=" ($revname)"
|
|
|
|
}
|
2008-03-11 14:52:15 +01:00
|
|
|
#
|
|
|
|
# Show commit summary for submodules in index or working tree
|
|
|
|
#
|
|
|
|
# If '--cached' is given, show summary between index and given commit,
|
|
|
|
# or between working tree and given commit
|
|
|
|
#
|
|
|
|
# $@ = [commit (default 'HEAD'),] requested paths (default all)
|
|
|
|
#
|
|
|
|
cmd_summary() {
|
2008-03-11 14:52:17 +01:00
|
|
|
summary_limit=-1
|
2008-04-12 17:05:31 +02:00
|
|
|
for_status=
|
2009-08-13 21:32:50 +02:00
|
|
|
diff_cmd=diff-index
|
2008-03-11 14:52:17 +01:00
|
|
|
|
2008-03-11 14:52:15 +01:00
|
|
|
# parse $args after "submodule ... summary".
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
--cached)
|
|
|
|
cached="$1"
|
|
|
|
;;
|
2009-08-13 21:32:50 +02:00
|
|
|
--files)
|
|
|
|
files="$1"
|
|
|
|
;;
|
2008-04-12 17:05:31 +02:00
|
|
|
--for-status)
|
|
|
|
for_status="$1"
|
|
|
|
;;
|
2008-03-11 14:52:17 +01:00
|
|
|
-n|--summary-limit)
|
|
|
|
if summary_limit=$(($2 + 0)) 2>/dev/null && test "$summary_limit" = "$2"
|
|
|
|
then
|
|
|
|
:
|
|
|
|
else
|
|
|
|
usage
|
|
|
|
fi
|
|
|
|
shift
|
|
|
|
;;
|
2008-03-11 14:52:15 +01:00
|
|
|
--)
|
|
|
|
shift
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
2007-06-27 01:40:58 +02:00
|
|
|
|
2008-03-11 14:52:17 +01:00
|
|
|
test $summary_limit = 0 && return
|
|
|
|
|
2010-02-16 11:21:14 +01:00
|
|
|
if rev=$(git rev-parse -q --verify --default HEAD ${1+"$1"})
|
2008-03-11 14:52:15 +01:00
|
|
|
then
|
|
|
|
head=$rev
|
2010-03-03 23:19:09 +01:00
|
|
|
test $# = 0 || shift
|
2010-02-16 11:21:14 +01:00
|
|
|
elif test -z "$1" -o "$1" = "HEAD"
|
|
|
|
then
|
2010-03-03 23:19:10 +01:00
|
|
|
# before the first commit: compare with an empty tree
|
|
|
|
head=$(git hash-object -w -t tree --stdin </dev/null)
|
2010-03-09 15:55:32 +01:00
|
|
|
test -z "$1" || shift
|
2008-03-11 14:52:15 +01:00
|
|
|
else
|
2010-02-16 11:21:14 +01:00
|
|
|
head="HEAD"
|
2008-03-11 14:52:15 +01:00
|
|
|
fi
|
|
|
|
|
2009-08-13 21:32:50 +02:00
|
|
|
if [ -n "$files" ]
|
|
|
|
then
|
|
|
|
test -n "$cached" &&
|
2012-07-25 16:53:09 +02:00
|
|
|
die "$(gettext "The --cached option cannot be used with the --files option")"
|
2009-08-13 21:32:50 +02:00
|
|
|
diff_cmd=diff-files
|
|
|
|
head=
|
|
|
|
fi
|
|
|
|
|
2008-03-11 14:52:15 +01:00
|
|
|
cd_to_toplevel
|
|
|
|
# Get modified modules cared by user
|
2010-06-25 16:56:02 +02:00
|
|
|
modules=$(git $diff_cmd $cached --ignore-submodules=dirty --raw $head -- "$@" |
|
2009-11-24 00:56:32 +01:00
|
|
|
sane_egrep '^:([0-7]* )?160000' |
|
2008-03-11 14:52:15 +01:00
|
|
|
while read mod_src mod_dst sha1_src sha1_dst status name
|
|
|
|
do
|
|
|
|
# Always show modules deleted or type-changed (blob<->module)
|
|
|
|
test $status = D -o $status = T && echo "$name" && continue
|
|
|
|
# Also show added or modified modules which are checked out
|
|
|
|
GIT_DIR="$name/.git" git-rev-parse --git-dir >/dev/null 2>&1 &&
|
|
|
|
echo "$name"
|
|
|
|
done
|
|
|
|
)
|
2008-03-11 14:52:16 +01:00
|
|
|
|
2008-04-12 17:05:31 +02:00
|
|
|
test -z "$modules" && return
|
|
|
|
|
2010-06-25 16:56:02 +02:00
|
|
|
git $diff_cmd $cached --ignore-submodules=dirty --raw $head -- $modules |
|
2009-11-24 00:56:32 +01:00
|
|
|
sane_egrep '^:([0-7]* )?160000' |
|
2008-03-11 14:52:16 +01:00
|
|
|
cut -c2- |
|
|
|
|
while read mod_src mod_dst sha1_src sha1_dst status name
|
|
|
|
do
|
|
|
|
if test -z "$cached" &&
|
|
|
|
test $sha1_dst = 0000000000000000000000000000000000000000
|
|
|
|
then
|
|
|
|
case "$mod_dst" in
|
|
|
|
160000)
|
|
|
|
sha1_dst=$(GIT_DIR="$name/.git" git rev-parse HEAD)
|
|
|
|
;;
|
|
|
|
100644 | 100755 | 120000)
|
|
|
|
sha1_dst=$(git hash-object $name)
|
|
|
|
;;
|
|
|
|
000000)
|
|
|
|
;; # removed
|
|
|
|
*)
|
|
|
|
# unexpected type
|
2011-08-07 13:58:17 +02:00
|
|
|
eval_gettextln "unexpected mode \$mod_dst" >&2
|
2008-03-11 14:52:16 +01:00
|
|
|
continue ;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
missing_src=
|
|
|
|
missing_dst=
|
|
|
|
|
|
|
|
test $mod_src = 160000 &&
|
2008-12-03 14:26:52 +01:00
|
|
|
! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_src^0 >/dev/null &&
|
2008-03-11 14:52:16 +01:00
|
|
|
missing_src=t
|
|
|
|
|
|
|
|
test $mod_dst = 160000 &&
|
2008-12-03 14:26:52 +01:00
|
|
|
! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_dst^0 >/dev/null &&
|
2008-03-11 14:52:16 +01:00
|
|
|
missing_dst=t
|
2007-06-27 01:40:58 +02:00
|
|
|
|
2008-03-11 14:52:16 +01:00
|
|
|
total_commits=
|
|
|
|
case "$missing_src,$missing_dst" in
|
|
|
|
t,)
|
2011-05-21 20:44:05 +02:00
|
|
|
errmsg="$(eval_gettext " Warn: \$name doesn't contain commit \$sha1_src")"
|
2008-03-11 14:52:16 +01:00
|
|
|
;;
|
|
|
|
,t)
|
2011-05-21 20:44:05 +02:00
|
|
|
errmsg="$(eval_gettext " Warn: \$name doesn't contain commit \$sha1_dst")"
|
2008-03-11 14:52:16 +01:00
|
|
|
;;
|
|
|
|
t,t)
|
2011-05-21 20:44:05 +02:00
|
|
|
errmsg="$(eval_gettext " Warn: \$name doesn't contain commits \$sha1_src and \$sha1_dst")"
|
2008-03-11 14:52:16 +01:00
|
|
|
;;
|
|
|
|
*)
|
|
|
|
errmsg=
|
|
|
|
total_commits=$(
|
|
|
|
if test $mod_src = 160000 -a $mod_dst = 160000
|
|
|
|
then
|
|
|
|
range="$sha1_src...$sha1_dst"
|
|
|
|
elif test $mod_src = 160000
|
|
|
|
then
|
|
|
|
range=$sha1_src
|
|
|
|
else
|
|
|
|
range=$sha1_dst
|
|
|
|
fi
|
|
|
|
GIT_DIR="$name/.git" \
|
2010-04-08 21:42:37 +02:00
|
|
|
git rev-list --first-parent $range -- | wc -l
|
2008-03-11 14:52:16 +01:00
|
|
|
)
|
2008-03-12 09:30:01 +01:00
|
|
|
total_commits=" ($(($total_commits + 0)))"
|
2008-03-11 14:52:16 +01:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
sha1_abbr_src=$(echo $sha1_src | cut -c1-7)
|
|
|
|
sha1_abbr_dst=$(echo $sha1_dst | cut -c1-7)
|
|
|
|
if test $status = T
|
|
|
|
then
|
2011-05-21 20:44:09 +02:00
|
|
|
blob="$(gettext "blob")"
|
|
|
|
submodule="$(gettext "submodule")"
|
2008-03-11 14:52:16 +01:00
|
|
|
if test $mod_dst = 160000
|
|
|
|
then
|
2011-05-21 20:44:09 +02:00
|
|
|
echo "* $name $sha1_abbr_src($blob)->$sha1_abbr_dst($submodule)$total_commits:"
|
2008-03-11 14:52:16 +01:00
|
|
|
else
|
2011-05-21 20:44:09 +02:00
|
|
|
echo "* $name $sha1_abbr_src($submodule)->$sha1_abbr_dst($blob)$total_commits:"
|
2008-03-11 14:52:16 +01:00
|
|
|
fi
|
|
|
|
else
|
|
|
|
echo "* $name $sha1_abbr_src...$sha1_abbr_dst$total_commits:"
|
|
|
|
fi
|
|
|
|
if test -n "$errmsg"
|
|
|
|
then
|
|
|
|
# Don't give error msg for modification whose dst is not submodule
|
|
|
|
# i.e. deleted or changed to blob
|
|
|
|
test $mod_dst = 160000 && echo "$errmsg"
|
|
|
|
else
|
|
|
|
if test $mod_src = 160000 -a $mod_dst = 160000
|
|
|
|
then
|
2008-03-11 14:52:17 +01:00
|
|
|
limit=
|
|
|
|
test $summary_limit -gt 0 && limit="-$summary_limit"
|
2008-03-11 14:52:16 +01:00
|
|
|
GIT_DIR="$name/.git" \
|
2008-03-11 14:52:17 +01:00
|
|
|
git log $limit --pretty='format: %m %s' \
|
2008-03-11 14:52:16 +01:00
|
|
|
--first-parent $sha1_src...$sha1_dst
|
|
|
|
elif test $mod_dst = 160000
|
|
|
|
then
|
|
|
|
GIT_DIR="$name/.git" \
|
|
|
|
git log --pretty='format: > %s' -1 $sha1_dst
|
|
|
|
else
|
|
|
|
GIT_DIR="$name/.git" \
|
|
|
|
git log --pretty='format: < %s' -1 $sha1_src
|
|
|
|
fi
|
|
|
|
echo
|
|
|
|
fi
|
|
|
|
echo
|
2008-04-12 17:05:31 +02:00
|
|
|
done |
|
|
|
|
if test -n "$for_status"; then
|
2010-01-17 20:42:31 +01:00
|
|
|
if [ -n "$files" ]; then
|
2013-01-16 20:18:48 +01:00
|
|
|
gettextln "Submodules changed but not updated:" | git stripspace -c
|
2010-01-17 20:42:31 +01:00
|
|
|
else
|
2013-01-16 20:18:48 +01:00
|
|
|
gettextln "Submodule changes to be committed:" | git stripspace -c
|
2010-01-17 20:42:31 +01:00
|
|
|
fi
|
2013-01-16 20:18:48 +01:00
|
|
|
printf "\n" | git stripspace -c
|
|
|
|
git stripspace -c
|
2008-04-12 17:05:31 +02:00
|
|
|
else
|
|
|
|
cat
|
|
|
|
fi
|
2008-03-11 14:52:15 +01:00
|
|
|
}
|
2007-05-26 15:56:40 +02:00
|
|
|
#
|
2007-06-11 21:12:24 +02:00
|
|
|
# List all submodules, prefixed with:
|
2007-05-26 15:56:40 +02:00
|
|
|
# - submodule not initialized
|
|
|
|
# + different revision checked out
|
|
|
|
#
|
|
|
|
# If --cached was specified the revision in the index will be printed
|
|
|
|
# instead of the currently checked out revision.
|
|
|
|
#
|
|
|
|
# $@ = requested paths (default to all)
|
|
|
|
#
|
2008-01-15 11:35:49 +01:00
|
|
|
cmd_status()
|
2007-05-26 15:56:40 +02:00
|
|
|
{
|
2008-01-15 11:48:45 +01:00
|
|
|
# parse $args after "submodule ... status".
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-q|--quiet)
|
2009-06-17 00:33:00 +02:00
|
|
|
GIT_QUIET=1
|
2008-01-15 11:48:45 +01:00
|
|
|
;;
|
|
|
|
--cached)
|
|
|
|
cached=1
|
|
|
|
;;
|
2009-08-19 03:45:24 +02:00
|
|
|
--recursive)
|
|
|
|
recursive=1
|
|
|
|
;;
|
2008-01-15 11:48:45 +01:00
|
|
|
--)
|
|
|
|
shift
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
2008-08-22 09:30:50 +02:00
|
|
|
module_list "$@" |
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
while read mode sha1 stage sm_path
|
2007-05-26 15:56:40 +02:00
|
|
|
do
|
2012-08-14 22:35:27 +02:00
|
|
|
die_if_unmatched "$mode"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
name=$(module_name "$sm_path") || exit
|
2007-07-03 07:52:14 +02:00
|
|
|
url=$(git config submodule."$name".url)
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
displaypath="$prefix$sm_path"
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 07:20:02 +02:00
|
|
|
if test "$stage" = U
|
|
|
|
then
|
|
|
|
say "U$sha1 $displaypath"
|
|
|
|
continue
|
|
|
|
fi
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -z "$url" || ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
|
2007-05-26 15:56:40 +02:00
|
|
|
then
|
2009-08-19 03:45:24 +02:00
|
|
|
say "-$sha1 $displaypath"
|
2007-05-26 15:56:40 +02:00
|
|
|
continue;
|
|
|
|
fi
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
set_name_rev "$sm_path" "$sha1"
|
|
|
|
if git diff-files --ignore-submodules=dirty --quiet -- "$sm_path"
|
2007-05-26 15:56:40 +02:00
|
|
|
then
|
2009-08-19 03:45:24 +02:00
|
|
|
say " $sha1 $displaypath$revname"
|
2007-05-26 15:56:40 +02:00
|
|
|
else
|
|
|
|
if test -z "$cached"
|
|
|
|
then
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
sha1=$(clear_local_git_env; cd "$sm_path" && git rev-parse --verify HEAD)
|
|
|
|
set_name_rev "$sm_path" "$sha1"
|
2007-05-26 15:56:40 +02:00
|
|
|
fi
|
2009-08-19 03:45:24 +02:00
|
|
|
say "+$sha1 $displaypath$revname"
|
|
|
|
fi
|
|
|
|
|
|
|
|
if test -n "$recursive"
|
|
|
|
then
|
|
|
|
(
|
|
|
|
prefix="$displaypath/"
|
2010-02-25 00:34:17 +01:00
|
|
|
clear_local_git_env
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
cd "$sm_path" &&
|
2012-10-28 22:37:16 +01:00
|
|
|
eval cmd_status
|
2009-08-19 03:45:24 +02:00
|
|
|
) ||
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
die "$(eval_gettext "Failed to recurse into submodule path '\$sm_path'")"
|
2007-05-26 15:56:40 +02:00
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
2008-08-24 21:43:37 +02:00
|
|
|
#
|
|
|
|
# Sync remote urls for submodules
|
|
|
|
# This makes the value for remote.$remote.url match the value
|
|
|
|
# specified in .gitmodules.
|
|
|
|
#
|
|
|
|
cmd_sync()
|
|
|
|
{
|
|
|
|
while test $# -ne 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-q|--quiet)
|
2009-06-17 00:33:00 +02:00
|
|
|
GIT_QUIET=1
|
2008-08-24 21:43:37 +02:00
|
|
|
shift
|
|
|
|
;;
|
2012-10-26 21:44:42 +02:00
|
|
|
--recursive)
|
|
|
|
recursive=1
|
|
|
|
shift
|
|
|
|
;;
|
2008-08-24 21:43:37 +02:00
|
|
|
--)
|
|
|
|
shift
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
cd_to_toplevel
|
|
|
|
module_list "$@" |
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
while read mode sha1 stage sm_path
|
2008-08-24 21:43:37 +02:00
|
|
|
do
|
2012-08-14 22:35:27 +02:00
|
|
|
die_if_unmatched "$mode"
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
name=$(module_name "$sm_path")
|
2008-08-24 21:43:37 +02:00
|
|
|
url=$(git config -f .gitmodules --get submodule."$name".url)
|
2008-09-22 18:08:31 +02:00
|
|
|
|
|
|
|
# Possibly a url relative to parent
|
|
|
|
case "$url" in
|
|
|
|
./*|../*)
|
2012-06-06 13:57:29 +02:00
|
|
|
# rewrite foo/bar as ../.. to find path from
|
|
|
|
# submodule work tree to superproject work tree
|
|
|
|
up_path="$(echo "$sm_path" | sed "s/[^/][^/]*/../g")" &&
|
|
|
|
# guarantee a trailing /
|
|
|
|
up_path=${up_path%/}/ &&
|
|
|
|
# path from submodule work tree to submodule origin repo
|
|
|
|
sub_origin_url=$(resolve_relative_url "$url" "$up_path") &&
|
|
|
|
# path from superproject work tree to submodule origin repo
|
|
|
|
super_config_url=$(resolve_relative_url "$url") || exit
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
sub_origin_url="$url"
|
|
|
|
super_config_url="$url"
|
2008-09-22 18:08:31 +02:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2011-06-25 22:41:25 +02:00
|
|
|
if git config "submodule.$name.url" >/dev/null 2>/dev/null
|
2008-08-24 21:43:37 +02:00
|
|
|
then
|
2012-10-26 21:44:42 +02:00
|
|
|
say "$(eval_gettext "Synchronizing submodule url for '\$prefix\$sm_path'")"
|
2012-06-06 13:57:29 +02:00
|
|
|
git config submodule."$name".url "$super_config_url"
|
2011-06-25 22:41:25 +02:00
|
|
|
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
if test -e "$sm_path"/.git
|
2011-06-25 22:41:25 +02:00
|
|
|
then
|
|
|
|
(
|
|
|
|
clear_local_git_env
|
git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.
Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.
In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)
As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17 20:00:58 +02:00
|
|
|
cd "$sm_path"
|
2011-06-25 22:41:25 +02:00
|
|
|
remote=$(get_default_remote)
|
2012-06-06 13:57:29 +02:00
|
|
|
git config remote."$remote".url "$sub_origin_url"
|
2012-10-26 21:44:42 +02:00
|
|
|
|
|
|
|
if test -n "$recursive"
|
|
|
|
then
|
|
|
|
prefix="$prefix$sm_path/"
|
|
|
|
eval cmd_sync
|
|
|
|
fi
|
2011-06-25 22:41:25 +02:00
|
|
|
)
|
|
|
|
fi
|
2008-08-24 21:43:37 +02:00
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
2007-05-26 15:56:40 +02:00
|
|
|
|
2008-01-15 11:48:45 +01:00
|
|
|
# This loop parses the command line arguments to find the
|
|
|
|
# subcommand name to dispatch. Parsing of the subcommand specific
|
|
|
|
# options are primarily done by the subcommand implementations.
|
|
|
|
# Subcommand specific options such as --branch and --cached are
|
|
|
|
# parsed here as well, for backward compatibility.
|
|
|
|
|
|
|
|
while test $# != 0 && test -z "$command"
|
2007-05-26 15:56:40 +02:00
|
|
|
do
|
|
|
|
case "$1" in
|
2008-08-24 21:43:37 +02:00
|
|
|
add | foreach | init | update | status | summary | sync)
|
2008-01-15 11:48:45 +01:00
|
|
|
command=$1
|
2007-05-26 15:56:40 +02:00
|
|
|
;;
|
|
|
|
-q|--quiet)
|
2009-06-17 00:33:00 +02:00
|
|
|
GIT_QUIET=1
|
2007-05-26 15:56:40 +02:00
|
|
|
;;
|
2007-06-24 23:06:07 +02:00
|
|
|
-b|--branch)
|
|
|
|
case "$2" in
|
|
|
|
'')
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
branch="$2"; shift
|
|
|
|
;;
|
2007-05-26 15:56:40 +02:00
|
|
|
--cached)
|
2008-03-11 14:52:15 +01:00
|
|
|
cached="$1"
|
2007-05-26 15:56:40 +02:00
|
|
|
;;
|
|
|
|
--)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
usage
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
|
2008-01-15 11:48:45 +01:00
|
|
|
# No command word defaults to "status"
|
2012-09-22 13:27:59 +02:00
|
|
|
if test -z "$command"
|
|
|
|
then
|
|
|
|
if test $# = 0
|
|
|
|
then
|
|
|
|
command=status
|
|
|
|
else
|
|
|
|
usage
|
|
|
|
fi
|
|
|
|
fi
|
2008-01-15 11:48:45 +01:00
|
|
|
|
|
|
|
# "-b branch" is accepted only by "add"
|
|
|
|
if test -n "$branch" && test "$command" != add
|
|
|
|
then
|
2007-06-24 23:06:07 +02:00
|
|
|
usage
|
2008-01-15 11:48:45 +01:00
|
|
|
fi
|
|
|
|
|
2008-03-11 14:52:15 +01:00
|
|
|
# "--cached" is accepted only by "status" and "summary"
|
|
|
|
if test -n "$cached" && test "$command" != status -a "$command" != summary
|
2008-01-15 11:48:45 +01:00
|
|
|
then
|
2007-05-26 15:56:40 +02:00
|
|
|
usage
|
2008-01-15 11:48:45 +01:00
|
|
|
fi
|
|
|
|
|
|
|
|
"cmd_$command" "$@"
|