When the configuration variable status.submodulesummary is not 0 or
false, "git status" shows the submodule summary of the staged submodule
commits. But it did not show the summary of those commits not yet
staged in the supermodule, making it hard to see what will not be
committed.
The output of "submodule summary --for-status" has been changed from
"# Modified submodules:" to "# Submodule changes to be committed:" for
the already staged changes. "# Submodules changed but not updated:" has
been added for changes that will not be committed. This is much clearer
and consistent with the output for regular files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the user has exported the GREP_OPTIONS environment variable, the output
from "grep" and "egrep" in scripted Porcelains may be different from what
they expect. For example, we may want to count number of matching lines,
by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use.
The approach taken by this change to address this issue is to protect only
our own use of grep/egrep. Because we do not unset it at the beginning of
our scripts, hook scripts run from the scripted Porcelains are exposed to
the same insanity this environment variable causes when grep/egrep is used
to implement logic (e.g. "grep | wc -l"), and it is entirely up to the
hook scripts to protect themselves.
On the other hand, applypatch-msg hook may want to show offending words in
the proposed commit log message using grep to the end user, and the user
might want to set GREP_OPTIONS=--color to paint the match more visibly.
The approach to protect only our own use without unsetting the environment
variable globally will allow this use case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When <path> is not given, use the "humanish" part of the source repository
instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only show
status for all the submodules in the current repo (which is what is
currently done by 'git submodule status'), but also to show status for
all submodules at all levels (i.e. recursing into nested submodules as
well).
This patch teaches the new --recursive option to the 'git submodule status'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only update
the submodules in the current repo (which is what is currently done by
'git submodule update'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule update'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only operate
on all the submodules in the current repo (which is what is currently done
by 'git submodule foreach'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule foreach'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The argument to 'git submodule foreach' already has access to the variables
'$path' (the path to the submodule, relative to the superproject) and '$sha1'
(the submodule commit recorded by the superproject).
This patch adds another variable -- '$name' -- which contains the name of the
submodule, as recorded in the superproject's .gitmodules file.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git submodule summary is providing similar functionality for submodules as
git diff-index does for a git project (including the meaning of --cached).
But the analogon to git diff-files is missing, so add a --files option to
summarize the differences between the index of the super project and the
last commit checked out in the working tree of the submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that there is say() in git-sh-setup, these scripts don't need to use
their own. Migrate them over by setting GIT_QUIET and removing their
custom say() functions.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git submodule update --merge' merges the commit referenced by the
superproject into your local branch, instead of checking it out on
a detached HEAD.
As evidenced by the addition of "git submodule update --rebase", it
is useful to provide alternatives to the default 'checkout' behaviour
of "git submodule update". One such alternative is, when updating a
submodule to a new commit, to merge that commit into the current
local branch in that submodule. This is useful in workflows where
you want to update your submodule from its upstream, but you cannot
use --rebase, because you have downstream people working on top of
your submodule branch, and you don't want to disrupt their work.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
This adds --reference option to git submodule add and
git submodule update commands, which is passed to git clone.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git submodule update --rebase' rebases your local branch on top of what
would have been checked out to a detached HEAD otherwise.
In some cases, detaching the HEAD when updating a submodule complicates
the workflow to commit to this submodule (checkout master, rebase, then
commit). For submodules that require frequent updates but infrequent
(if any) commits, a rebase can be executed directly by the git-submodule
command, ensuring that the submodules stay on their respective branches.
git-config key: submodule.$name.rebase (bool)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ash (used as /bin/sh on many distros) has a shell expansion bug
for the form ${var:+word word}. The result is a single argument
"word word". Work around by using ${var:+word} ${var:+word} or
equivalent.
Signed-off-by: Ben Jackson <ben@ben.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Actually, you have to set the -b option after the add command.
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make 'git submodule add' normalize the submodule path in the
same way as 'git ls-files' does, so that 'git submodule init' looks up
the information in .gitmodules with the same key under which 'git
submodule add' stores it.
This fixes 4 known breakages.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, when you called
git submodule some/bogus/path
Git would silently ignore the path, without warning the user about the
likely mistake. Now it does.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git submodule update --no-fetch makes it possible to use git submodule
update in complete offline mode by not fetching new revisions.
This does make sense in the following setup:
* There is an unstable and a stable branch in the super/master repository.
* The submodules might be at different revisions in the branches.
* You are at some place without internet connection ;)
With this patch it is now possible to change branches and update
the submodules to be at the recorded revision without online access.
Another advantage is that with -N the update operation is faster, because fetch is checking for new updates even if there was no fetch/pull on the super/master repository since the last update.
Signed-off-by: Fabian Franz <git@fabian-franz.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix 'git submodule update' to avoid printing a spurious "Maybe you want
to use 'update --init'?" once for every uninitialized submodule it
encounters.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not all greps support "-e", but in this case we can easily convert it to a
single extended regex.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 55218("checkout: do not lose staged removal"), in
cmd_add/cmd_update, "git checkout <commit>" following
"git clone -n" may fail if <commit> is different from HEAD.
So Use "git checkout -f <commit>" to fix this.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When a submodule's URL changes upstream, existing submodules
will be out of sync since their remote."$origin".url will still
be set to the old value.
This adds a "git submodule sync" command that reads submodules'
URLs from .gitmodules and updates them accordingly.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resolve_relative_url was using its own code for this function, but
this is duplication with the best result that this continues to work.
Replace with the common function provided by git-parse-remote.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several call sites in git-submodule.sh used the same idiom for getting
submodule information:
git ls-files --stage -- "$@" | grep '^160000 '
This patch removes this duplication by introducing a module_list function.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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. Regardless of whether git is changed to remove the
trailing / before recording the URL, we should avoid this issue in
submodule as existing repositories can have this problem.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule foreach <command-list> will execute the list of commands in
each currently checked out submodule directory. The list of commands
is arbitrary as long as it is acceptable to sh. The variables '$path'
and '$sha1' are availble to the command-list, defining the submodule
path relative to the superproject and the submodules's commitID as
recorded in the superproject (this may be different than HEAD in the
submodule).
This utility is inspired by a number of threads on the mailing list
looking for ways to better integrate submodules in a tree and work
with them as a unit. This could include fetching a new branch in each
from a given source, or possibly checking out a given named branch in
each. Currently, there is no consensus as to what additional commands
should be implemented in the porcelain, requiring all users whose needs
exceed that of git-submodule to do their own scripting. The foreach
command is intended to support such scripting, and in particular does
no error checking and produces no output, thus allowing end users
complete control over any information printed out and over what
constitutes an error. The processing does terminate if the command-list
returns an error, but processing can easily be forced for all
submodules be terminating the list with ';true'.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running git submodule update -i, the "-i" is shifted before recursing
into cmd_init and then again outside of the loop. This causes some /bin/sh
to complain about shifting when there are no arguments left (and would
discard anything written after -i too).
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running git submodule update -i, the "-i" is shifted before recursing
into cmd_init and then again outside of the loop. This causes some /bin/sh
to complain about shifting when there are no arguments left (and would
discard anything written after -i too).
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When adding a new submodule in place, meaning the user created the
submodule as a git repo in the superproject's tree first, we don't go
through "git submodule init" to register the module. Thus, the
submodule's origin repository URL is not stored in .git/config, and no
subsequent submodule operation will ever do so. In this case, assume the
URL the user supplies to "submodule add" is the one that should be
registered, and do so.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
git-submodule add would trip if path to the submodule included a space,
or if its .git was a gitdir: link to a GIT_DIR kept elsewhere. Fix both.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule was invoking "die" from within resolve-relative-url, but
this does not actually cause the script to exit. Fix this by returning
the error to the caller and have the caller exit.
While we're at it, clean up the quoting on invocation of
resolve_relative_url as it was wrong.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The behaviour of "sed" on an incomplete line is unspecified by POSIX, and
On Solaris it apparently fails to process input that doesn't end in a LF.
Consequently constructs like
re=$(printf '%s' foo | sed -e 's/bar/BAR/g' $)
cause re to be set to the empty string. Such a construct is used in
git-submodule.sh.
Because the LF at the end of command output are stripped away by the
command substitution, it is a safe and sane change to add a LF at the end
of the printf format specifier.
Signed-off-by: Chris Ridd <chris.ridd@isode.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a submodule is not initialized and you do not want to change the
defaults from .gitmodules anyway, you can now say
$ git submodule update --init <name>
When "update" is called without --init on an uninitialized submodule,
a hint to use --init is printed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git config' has a '-f' option that takes the file to parse.
Using it rather than the environment variable seems more logical
and simplified.
Signed-off-by: Imran M Yousuf <imyousuf@smartitengineering.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes the search logic for describing a submodule from:
- annotated tag
- any tag
- tag on a subsequent commit
- commit id
to
- annotated tag
- any tag
- tag on a subsequent commit
- local or remote branch
- commit id
The change is describing with respect to a branch before falling
back to the commit id. By itself, git-submodule will maintain submodules
as headless checkouts without ever making a local branch. In
general, such heads can always be described relative to the remote branch
regardless of existence of tags, and so provides a better fallback
summary than just the commit id.
This requires inserting an extra describe step as --contains is
incompatible with --all, but the latter can be used with --always
to fall back to a commit ID. Also, --contains implies --tags, so the
latter is not needed.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --for-status option is mainly used by builtin-status/commit.
It adds 'Modified submodules:' line at top and '# ' prefix to all
following lines.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git submodule status" command tries to show the name of the
submodule HEAD revision more descriptively, but the submodule
repository lacked a suitable tag to do so, it leaked "fatal: cannot
describe" message to the UI. Squelch it by using '--always'.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-submodule tries to detect 'active' submodules, it checks for the
existence of a directory named '.git'. This isn't good enough now that .git
can be a file pointing to the real $GIT_DIR so the tests are changed to
reflect this.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
System V versions of grep (such as Solaris /usr/bin/grep)
don't understand either of these options. git's usage of
"grep -e pattern" fell into one of two categories:
1. equivalent to "grep pattern". -e is only useful here if
the pattern begins with a "-", but all of the patterns
are hardcoded and do not begin with a dash.
2. stripping comments and blank lines with
grep -v -e "^$" -e "^#"
We can fortunately do this in the affirmative as
grep '^[^#]'
Uses of "-q" can be replaced with redirection to /dev/null.
In many tests, however, "grep -q" is used as "if this string
is in the expected output, we are OK". In this case, it is
fine to just remove the "-q" entirely; it simply makes the
"verbose" mode of the test slightly more verbose.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We print the number of commits in parentheses, but without this change
we would get an oddly looking line like this:
* sm1 4c8d358...41fbea9 ( 4):
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch teaches git-submodule an option '--summary-limit|-n <number>'
to limit number of commits in total for the summary of each submodule in
the modified case (only a single commit is shown in other cases).
Giving 0 will disable the summary; a negative number means unlimted, which
is the default.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
These patches teach git-submodule a new subcommand 'summary' to show
commit summary of checked out submodules between a given super project
commit (defaults to HEAD) and working tree (or index, when --cached is
given).
This patch just introduces the framework to find submodules which have
summary to show. A submodule will have summary if it falls into these
cases:
- type 'M': modified and checked out (1)
- type 'A': added and checked out (2)
- type 'D': deleted
- type 'T': typechanged (blob <-> submodule)
Notes:
1. There may be modified but not checked out cases. In the case of a
merge conflict, even if the submodule is not checked out, there may
be still a diff between index and HEAD on the submodule entry
(i.e. modified). The summary will not be show for such a submodule.
2. A similar explanation applies to the added but not checked out case.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working in the top-level project, it is useful to create a new
submodule as a git repo in a subdirectory, then add that submodule to
the top-level in place.
This patch allows "git submodule add <intended url> subdir" to add the
existing subdir to the current project. The presumption is the user will
later push / clone the subdir to the <intended url> so that future
submodule init / updates will work.
Absent this patch, "git submodule add" insists upon cloning the subdir
from a repository at the given url, which is fine for adding an existing
project in, but less useful when adding a new submodule from scratch to an
existing project. The former functionality remains, and the clone is
attempted if the subdir does not already exist as a valid git repo.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jens Lehmann