git-commit-vandalism/git-submodule.sh

999 lines
20 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# git-submodules.sh: add, init, update or list git submodules
#
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
. git-parse-remote
require_work_tree
command=
branch=
force=
reference=
cached=
recursive=
init=
files=
nofetch=
update=
prefix=
# Resolve relative url by appending to parent's url
resolve_relative_url ()
{
remote=$(get_default_remote)
remoteurl=$(git config "remote.$remote.url") ||
remoteurl=$(pwd) # the repository is its own authoritative upstream
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%/}
sep=/
while test -n "$url"
do
case "$url" in
../*)
url="${url#../}"
case "$remoteurl" in
*/*)
remoteurl="${remoteurl%/*}"
;;
*:*)
remoteurl="${remoteurl%:*}"
sep=:
;;
*)
die "$(eval_gettext "cannot strip one component off url '\$remoteurl'")"
;;
esac
;;
./*)
url="${url#./}"
;;
*)
break;;
esac
done
echo "$remoteurl$sep${url%/}"
}
#
# Get submodule info for registered submodules
# $@ = path to limit submodule list
#
module_list()
{
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
git ls-files --error-unmatch --stage -- "$@" |
perl -e '
my %unmerged = ();
my ($null_sha1) = ("0" x 40);
while (<STDIN>) {
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}++) {
print "$mode $null_sha1 U\t$path\n";
}
next;
}
print "$_\n";
}
'
}
#
# Map submodule path to submodule name
#
# $1 = path
#
module_name()
{
# Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
test -z "$name" &&
die "$(eval_gettext "No submodule mapping found in .gitmodules for path '\$path'")"
echo "$name"
}
#
# Clone a submodule
#
# Prior to calling, cmd_update checks that a possibly existing
# path is not a git repository.
# Likewise, cmd_add checks that path does not exist at all,
# since it is the location of a new submodule.
#
module_clone()
{
path=$1
url=$2
reference="$3"
quiet=
if test -n "$GIT_QUIET"
then
quiet=-q
fi
if test -n "$reference"
then
git-clone $quiet "$reference" -n "$url" "$path"
else
git-clone $quiet -n "$url" "$path"
fi ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
}
#
# 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
#
# optional branch is stored in global branch variable
#
cmd_add()
{
# parse $args after "submodule ... add".
while test $# -ne 0
do
case "$1" in
-b | --branch)
case "$2" in '') usage ;; esac
branch=$2
shift
;;
-f | --force)
force=$1
;;
-q|--quiet)
GIT_QUIET=1
;;
--reference)
case "$2" in '') usage ;; esac
reference="--reference=$2"
shift
;;
--reference=*)
reference="$1"
shift
;;
--)
shift
break
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
repo=$1
path=$2
if test -z "$path"; then
path=$(echo "$repo" |
sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
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
if test -z "$repo" -o -z "$path"; then
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
;;
*)
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
# normalize path:
# multiple //; leading ./; /./; /../; trailing /
path=$(printf '%s/\n' "$path" |
sed -e '
s|//*|/|g
s|^\(\./\)*||
s|/\./|/|g
:start
s|\([^/]*\)/\.\./||
tstart
s|/*$||
')
git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
die "$(eval_gettext "'\$path' already exists in the index")"
if test -z "$force" && ! git add --dry-run --ignore-missing "$path" > /dev/null 2>&1
then
(
eval_gettext "The following path is ignored by one of your .gitignore files:
\$path
Use -f if you really want to add it." &&
echo
) >&2
exit 1
fi
# perhaps the path exists and is already a git repo, else clone it
if test -e "$path"
then
if test -d "$path"/.git -o -f "$path"/.git
then
eval_gettext "Adding existing repo at '\$path' to the index"; echo
else
die "$(eval_gettext "'\$path' already exists and is not a valid git repo")"
fi
else
module_clone "$path" "$realrepo" "$reference" || exit
(
clear_local_git_env
cd "$path" &&
# ash fails to wordsplit ${branch:+-b "$branch"...}
case "$branch" in
'') git checkout -f -q ;;
?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
esac
) || die "$(eval_gettext "Unable to checkout submodule '\$path'")"
fi
git config submodule."$path".url "$realrepo"
git add $force "$path" ||
die "$(eval_gettext "Failed to add submodule '\$path'")"
git config -f .gitmodules submodule."$path".path "$path" &&
git config -f .gitmodules submodule."$path".url "$repo" &&
git submodule: add submodules with git add -f <path> Change `git submodule add' to add the new submodule <path> with `git add --force'. I keep my /etc in .git with a .gitignore that contains just "*". I.e. `git status' will ignore everything that isn't in the tree already. When I do: git submodule add <url> hlagh git-submodule will get as far as checking out the remote repository into hlagh, but it'll die right afterwards when it fails to add the new path: The following paths are ignored by one of your .gitignore files: hlagh Use -f if you really want to add them. fatal: no files added Failed to add submodule 'hlagh' Currently there's no way to add a submodule in this situation other than to remove the ignored path from the .gitignore while I'm at it. That's silly, when you run `git submodule add' you're explicitly saying that you want to add something *new* to the repository. Instead it should just add the path with `git add --force'. Initially I implemented this by adding new -f and --force options to `git submodule add'. But if the --force option isn't supplied it'll get as far as cloning `hlagh', but won't add it. So the first thing the user has to do is to remove `hlagh' and then try again with the --force option. That sucks, it should just add the path to begin with. I can't think of any usecase where you've gone through the trouble of typing out `git submodule add ..', but wish to be overriden by a `gitignore'. The submodule semantics should be more like `git init', not `git add'. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 19:33:03 +02:00
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$path'")"
}
#
# Execute an arbitrary command sequence in each checked out
# submodule
#
# $@ = command to execute
#
cmd_foreach()
{
# parse $args after "submodule ... foreach".
while test $# -ne 0
do
case "$1" in
-q|--quiet)
GIT_QUIET=1
;;
--recursive)
recursive=1
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
git-submodule foreach: Add $toplevel variable Add a $toplevel variable accessible to `git submodule foreach`, it contains the absolute path of the top level directory (where .gitmodules is). This makes it possible to e.g. read data in .gitmodules from within foreach commands. I'm using this to configure the branch names I want to track for each submodule: git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' For a little history: This patch is borne out of my continuing fight of trying to have Git track the branches of submodules, not just their commits. Obviously that's not how they work (they only track commits), but I'm just interested in being able to do: git submodule foreach 'git pull' Of course that won't work because the submodule is in a disconnected head, so I first have to connect it, but connect it *to what*. For a while I was happy with this because as fate had it, it just so happened to do what I meant: git submodule foreach 'git checkout $(git describe --all --always) && git pull' But then that broke down, if there's a tag and a branch the tag will win out, and I can't git pull a branch: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master $ git tag -l release-0.0.6 $ git describe --always --all release-0.0.6 So I figured that I might as well start tracking the branches I want in .gitmodules itself: [submodule "yaml-mode"] path = yaml-mode url = git://github.com/yoshiki/yaml-mode.git branch = master So now I can just do (as stated above): git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' Maybe there's a less painful way to do *that* (I'd love to hear about it). But regardless of that I think it's a good idea to be able to know what the top-level is from git submodule foreach. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21 18:10:10 +02:00
toplevel=$(pwd)
git-submodule.sh: preserve stdin for the command spawned by foreach The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. The user-supplied command supplied to 'submodule foreach' is spawned within a while loop which is being piped into. Due to the way shells implement piping output to a while loop, a subshell is created with its standard input attached to the output of the pipe. This results in all of the commands executed within the while loop to have their stdins modified in the same way, including the user-supplied command. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not. For example, this problem was noticed when trying to execute the following: git submodule foreach git shortlog --since=two.weeks.ago which printed a message about entering the first submodule and produced no further output and exited with a status of zero. In this case, shortlog detected that it was not connected to a tty, and since no revision was supplied as an argument, it attempted to read the list of revisions from standard input. Instead, it slurped up the list of submodules that was being piped to the enclosing while loop and caused that loop to end early without processing the remaining submodules. Work around this behavior by saving the original standard input file descriptor before the while loop, and restoring it when spawning the user-supplied command. This fixes the tests in t7407. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
module_list |
while read mode sha1 stage path
do
if test -e "$path"/.git
then
say "$(eval_gettext "Entering '\$prefix\$path'")"
name=$(module_name "$path")
(
prefix="$prefix$path/"
clear_local_git_env
cd "$path" &&
eval "$@" &&
if test -n "$recursive"
then
cmd_foreach "--recursive" "$@"
fi
git-submodule.sh: preserve stdin for the command spawned by foreach The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. The user-supplied command supplied to 'submodule foreach' is spawned within a while loop which is being piped into. Due to the way shells implement piping output to a while loop, a subshell is created with its standard input attached to the output of the pipe. This results in all of the commands executed within the while loop to have their stdins modified in the same way, including the user-supplied command. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not. For example, this problem was noticed when trying to execute the following: git submodule foreach git shortlog --since=two.weeks.ago which printed a message about entering the first submodule and produced no further output and exited with a status of zero. In this case, shortlog detected that it was not connected to a tty, and since no revision was supplied as an argument, it attempted to read the list of revisions from standard input. Instead, it slurped up the list of submodules that was being piped to the enclosing while loop and caused that loop to end early without processing the remaining submodules. Work around this behavior by saving the original standard input file descriptor before the while loop, and restoring it when spawning the user-supplied command. This fixes the tests in t7407. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-30 02:34:58 +02:00
) <&3 3<&- ||
die "$(eval_gettext "Stopping at '\$path'; script returned non-zero status.")"
fi
done
}
#
# Register submodules in .git/config
#
# $@ = requested paths (default to all)
#
cmd_init()
{
# parse $args after "submodule ... init".
while test $# -ne 0
do
case "$1" in
-q|--quiet)
GIT_QUIET=1
;;
--)
shift
break
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
module_list "$@" |
while read mode sha1 stage path
do
# Skip already registered paths
name=$(module_name "$path") || exit
if test -z "$(git config "submodule.$name.url")"
then
url=$(git config -f .gitmodules submodule."$name".url)
test -z "$url" &&
die "$(eval_gettext "No url found for submodule path '\$path' in .gitmodules")"
# Possibly a url relative to parent
case "$url" in
./*|../*)
url=$(resolve_relative_url "$url") || exit
;;
esac
git config submodule."$name".url "$url" ||
die "$(eval_gettext "Failed to register url for submodule path '\$path'")"
fi
# Copy "update" setting when it is not set yet
upd="$(git config -f .gitmodules submodule."$name".update)"
test -z "$upd" ||
test -n "$(git config submodule."$name".update)" ||
git config submodule."$name".update "$upd" ||
die "$(eval_gettext "Failed to register update mode for submodule path '\$path'")"
say "$(eval_gettext "Submodule '\$name' (\$url) registered for path '\$path'")"
done
}
#
# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
#
cmd_update()
{
# parse $args after "submodule ... update".
orig_flags=
while test $# -ne 0
do
case "$1" in
-q|--quiet)
GIT_QUIET=1
;;
-i|--init)
init=1
;;
-N|--no-fetch)
nofetch=1
;;
-f|--force)
force=$1
;;
-r|--rebase)
update="rebase"
;;
--reference)
case "$2" in '') usage ;; esac
reference="--reference=$2"
orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
shift
;;
--reference=*)
reference="$1"
;;
-m|--merge)
update="merge"
;;
--recursive)
recursive=1
;;
--)
shift
break
;;
-*)
usage
;;
*)
break
;;
esac
orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
shift
done
if test -n "$init"
then
cmd_init "--" "$@" || return
fi
cloned_modules=
module_list "$@" | {
err=
while read mode sha1 stage path
do
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
echo >&2 "Skipping unmerged submodule $path"
continue
fi
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
update_module=$(git config submodule."$name".update)
if test -z "$url"
then
# Only mention uninitialized submodules when its
# path have been specified
test "$#" != "0" &&
say "$(eval_gettext "Submodule path '\$path' not initialized
Maybe you want to use 'update --init'?")"
continue
fi
if ! test -d "$path"/.git -o -f "$path"/.git
then
module_clone "$path" "$url" "$reference"|| exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
subsha1=$(clear_local_git_env; cd "$path" &&
git rev-parse --verify HEAD) ||
die "$(eval_gettext "Unable to find current revision in submodule path '\$path'")"
fi
if ! test -z "$update"
then
update_module=$update
fi
if test "$subsha1" != "$sha1"
then
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"
then
subforce="-f"
fi
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
# Is this something we just cloned?
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
update_module= ;;
esac
must_die_on_failure=
case "$update_module" in
rebase)
command="git rebase"
die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$path'")"
say_msg="$(eval_gettext "Submodule path '\$path': rebased into '\$sha1'")"
must_die_on_failure=yes
;;
merge)
command="git merge"
die_msg="$(eval_gettext "Unable to merge '\$sha1' in submodule path '\$path'")"
say_msg="$(eval_gettext "Submodule path '\$path': merged in '\$sha1'")"
must_die_on_failure=yes
;;
*)
command="git checkout $subforce -q"
die_msg="$(eval_gettext "Unable to checkout '\$sha1' in submodule path '\$path'")"
say_msg="$(eval_gettext "Submodule path '\$path': checked out '\$sha1'")"
;;
esac
if (clear_local_git_env; cd "$path" && $command "$sha1")
then
say "$say_msg"
elif test -n "$must_die_on_failure"
then
die_with_status 2 "$die_msg"
else
err="${err};$die_msg"
continue
fi
fi
if test -n "$recursive"
then
(clear_local_git_env; cd "$path" && eval cmd_update "$orig_flags")
res=$?
if test $res -gt 0
then
die_msg="$(eval_gettext "Failed to recurse into submodule path '\$path'")"
if test $res -eq 1
then
err="${err};$die_msg"
continue
else
die_with_status $res "$die_msg"
fi
fi
fi
done
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
}
}
set_name_rev () {
revname=$( (
clear_local_git_env
cd "$1" && {
git describe "$2" 2>/dev/null ||
git describe --tags "$2" 2>/dev/null ||
git describe --contains "$2" 2>/dev/null ||
git describe --all --always "$2"
}
) )
test -z "$revname" || revname=" ($revname)"
}
#
# 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() {
summary_limit=-1
for_status=
diff_cmd=diff-index
# parse $args after "submodule ... summary".
while test $# -ne 0
do
case "$1" in
--cached)
cached="$1"
;;
--files)
files="$1"
;;
--for-status)
for_status="$1"
;;
-n|--summary-limit)
if summary_limit=$(($2 + 0)) 2>/dev/null && test "$summary_limit" = "$2"
then
:
else
usage
fi
shift
;;
--)
shift
break
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
test $summary_limit = 0 && return
if rev=$(git rev-parse -q --verify --default HEAD ${1+"$1"})
then
head=$rev
test $# = 0 || shift
elif test -z "$1" -o "$1" = "HEAD"
then
# before the first commit: compare with an empty tree
head=$(git hash-object -w -t tree --stdin </dev/null)
test -z "$1" || shift
else
head="HEAD"
fi
if [ -n "$files" ]
then
test -n "$cached" &&
die "$(gettext -- "--cached cannot be used with --files")"
diff_cmd=diff-files
head=
fi
cd_to_toplevel
# Get modified modules cared by user
modules=$(git $diff_cmd $cached --ignore-submodules=dirty --raw $head -- "$@" |
sane_egrep '^:([0-7]* )?160000' |
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
)
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
test -z "$modules" && return
git $diff_cmd $cached --ignore-submodules=dirty --raw $head -- $modules |
sane_egrep '^:([0-7]* )?160000' |
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
(
eval_gettext "unexpected mode \$mod_dst" &&
echo
) >&2
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
continue ;;
esac
fi
missing_src=
missing_dst=
test $mod_src = 160000 &&
! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_src^0 >/dev/null &&
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
missing_src=t
test $mod_dst = 160000 &&
! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_dst^0 >/dev/null &&
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
missing_dst=t
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
total_commits=
case "$missing_src,$missing_dst" in
t,)
errmsg="$(eval_gettext " Warn: \$name doesn't contain commit \$sha1_src")"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
;;
,t)
errmsg="$(eval_gettext " Warn: \$name doesn't contain commit \$sha1_dst")"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
;;
t,t)
errmsg="$(eval_gettext " Warn: \$name doesn't contain commits \$sha1_src and \$sha1_dst")"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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" \
git rev-list --first-parent $range -- | wc -l
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
)
total_commits=" ($(($total_commits + 0)))"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
blob="$(gettext "blob")"
submodule="$(gettext "submodule")"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
if test $mod_dst = 160000
then
echo "* $name $sha1_abbr_src($blob)->$sha1_abbr_dst($submodule)$total_commits:"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
else
echo "* $name $sha1_abbr_src($submodule)->$sha1_abbr_dst($blob)$total_commits:"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
limit=
test $summary_limit -gt 0 && limit="-$summary_limit"
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-11 14:52:16 +01:00
GIT_DIR="$name/.git" \
git log $limit --pretty='format: %m %s' \
git-submodule summary: show commit summary This patch does the hard work to show submodule commit summary. For a modified submodule, a series of commits will be shown with the following command: git log --pretty='format:%m %s' \ --first-parent sha1_src...sha1_dst where the sha1_src is from the given super project commit and the sha1_dst is from the index or working tree (switched by --cached). For a deleted, added, or typechanged (blob<->submodule) submodule, only one single newest commit from the existing end (for example, src end for submodule deleted or type changed from submodule to blob) will be shown. If the src/dst sha1 for a submodule is missing in the submodule directory, a warning will be issued except in two cases where the submodule directory is deleted (type 'D') or typechanged to blob (one case of type 'T'). In the title line for a submodule, the src/dst sha1 and the number of commits (--first-parent) between the two commits will be shown. The following example demonstrates most cases. Example: commit summary for modified submodules sm1-sm5. -------------------------------------------- $ git submodule summary * sm1 354cd45...3f751e5 (4): < one line message for C < one line message for B > one line message for D > one line message for E * sm2 5c8bfb5...000000 (3): < one line message for F * sm3 354cd45...3f751e5: Warn: sm3 doesn't contain commit 354cd45 * sm4 354cd34(submodule)-> 235efa(blob) (1): < one line message for G * sm5 354cd34(blob)-> 235efa(submodule) (5): > one line message for H -------------------------------------------- Signed-off-by: Ping Yin <pkufranky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
done |
if test -n "$for_status"; then
if [ -n "$files" ]; then
gettext "# Submodules changed but not updated:"; echo
else
gettext "# Submodule changes to be committed:"; echo
fi
echo "#"
sed -e 's|^|# |' -e 's|^# $|#|'
else
cat
fi
}
#
# List all submodules, prefixed with:
# - 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)
#
cmd_status()
{
# parse $args after "submodule ... status".
orig_flags=
while test $# -ne 0
do
case "$1" in
-q|--quiet)
GIT_QUIET=1
;;
--cached)
cached=1
;;
--recursive)
recursive=1
;;
--)
shift
break
;;
-*)
usage
;;
*)
break
;;
esac
orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
shift
done
module_list "$@" |
while read mode sha1 stage path
do
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
displaypath="$prefix$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
if test -z "$url" || ! test -d "$path"/.git -o -f "$path"/.git
then
say "-$sha1 $displaypath"
continue;
fi
set_name_rev "$path" "$sha1"
if git diff-files --ignore-submodules=dirty --quiet -- "$path"
then
say " $sha1 $displaypath$revname"
else
if test -z "$cached"
then
sha1=$(clear_local_git_env; cd "$path" && git rev-parse --verify HEAD)
set_name_rev "$path" "$sha1"
fi
say "+$sha1 $displaypath$revname"
fi
if test -n "$recursive"
then
(
prefix="$displaypath/"
clear_local_git_env
cd "$path" &&
eval cmd_status "$orig_args"
) ||
die "$(eval_gettext "Failed to recurse into submodule path '\$path'")"
fi
done
}
#
# 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)
GIT_QUIET=1
shift
;;
--)
shift
break
;;
-*)
usage
;;
*)
break
;;
esac
done
cd_to_toplevel
module_list "$@" |
while read mode sha1 stage path
do
name=$(module_name "$path")
url=$(git config -f .gitmodules --get submodule."$name".url)
# Possibly a url relative to parent
case "$url" in
./*|../*)
url=$(resolve_relative_url "$url") || exit
;;
esac
if git config "submodule.$name.url" >/dev/null 2>/dev/null
then
say "$(eval_gettext "Synchronizing submodule url for '\$name'")"
git config submodule."$name".url "$url"
if test -e "$path"/.git
then
(
clear_local_git_env
cd "$path"
remote=$(get_default_remote)
git config remote."$remote".url "$url"
)
fi
fi
done
}
# 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"
do
case "$1" in
add | foreach | init | update | status | summary | sync)
command=$1
;;
-q|--quiet)
GIT_QUIET=1
;;
-b|--branch)
case "$2" in
'')
usage
;;
esac
branch="$2"; shift
;;
--cached)
cached="$1"
;;
--)
break
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
# No command word defaults to "status"
test -n "$command" || command=status
# "-b branch" is accepted only by "add"
if test -n "$branch" && test "$command" != add
then
usage
fi
# "--cached" is accepted only by "status" and "summary"
if test -n "$cached" && test "$command" != status -a "$command" != summary
then
usage
fi
"cmd_$command" "$@"