* sb/quiet-porcelains:
stash: teach quiet option
am, rebase: teach quiet option
submodule, repack: migrate to git-sh-setup's say()
git-sh-setup: introduce say() for quiet options
am: suppress apply errors when using 3-way
t4150: test applying with a newline in subject
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>
* mg/maint-submodule-normalize-path:
git submodule: Fix adding of submodules at paths with ./, .. and //
git submodule: Add test cases for git submodule add
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>
* maint:
Fix non-literal format in printf-style calls
git-submodule: Avoid printing a spurious message.
git ls-remote: make usage string match manpage
Makefile: help people who run 'make check' by mistake
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>
* bc/master-diff-hunk-header-fix:
Clarify commit error message for unmerged files
Use strchrnul() instead of strchr() plus manual workaround
Use remove_path from dir.c instead of own implementation
Add remove_path: a function to remove as much as possible of a path
git-submodule: Fix "Unable to checkout" for the initial 'update'
Clarify how the user can satisfy stash's 'dirty state' check.
t4018-diff-funcname: test syntax of builtin xfuncname patterns
t4018-diff-funcname: test syntax of builtin xfuncname patterns
make "git remote" report multiple URLs
diff hunk pattern: fix misconverted "\{" tex macro introducers
diff: fix "multiple regexp" semantics to find hunk header comment
diff: use extended regexp to find hunk headers
diff: use extended regexp to find hunk headers
diff.*.xfuncname which uses "extended" regex's for hunk header selection
diff.c: associate a flag with each pattern and use it for compiling regex
diff.c: return pattern entry pointer rather than just the hunk header pattern
Conflicts:
builtin-merge-recursive.c
t/t7201-co.sh
xdiff-interface.h
* maint: (41 commits)
Clarify commit error message for unmerged files
Use strchrnul() instead of strchr() plus manual workaround
Use remove_path from dir.c instead of own implementation
Add remove_path: a function to remove as much as possible of a path
git-submodule: Fix "Unable to checkout" for the initial 'update'
Clarify how the user can satisfy stash's 'dirty state' check.
Remove empty directories in recursive merge
Documentation: clarify the details of overriding LESS via core.pager
Update release notes for 1.6.0.3
checkout: Do not show local changes when in quiet mode
for-each-ref: Fix --format=%(subject) for log message without newlines
git-stash.sh: don't default to refs/stash if invalid ref supplied
maint: check return of split_cmdline to avoid bad config strings
builtin-prune.c: prune temporary packs in <object_dir>/pack directory
Do not perform cross-directory renames when creating packs
Use dashless git commands in setgitperms.perl
git-remote: do not use user input in a printf format string
make "git remote" report multiple URLs
Start draft release notes for 1.6.0.3
git-repack uses --no-repack-object, not --no-repack-delta.
...
Conflicts:
RelNotes
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 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>
* lh/git-file:
Teach GIT-VERSION-GEN about the .git file
Teach git-submodule.sh about the .git file
Teach resolve_gitlink_ref() about the .git file
Add platform-independent .git "symlink"
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>
* jk/portable:
t6000lib: re-fix tr portability
t7505: use SHELL_PATH in hook
t9112: add missing #!/bin/sh header
filter-branch: use $SHELL_PATH instead of 'sh'
filter-branch: don't use xargs -0
add NO_EXTERNAL_GREP build option
t6000lib: tr portability fix
t4020: don't use grep -a
add test_cmp function for test scripts
remove use of "tail -n 1" and "tail -1"
grep portability fix: don't use "-e" or "-q"
more tr portability test script fixes
t0050: perl portability fix
tr portability fixes
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>
