Commit Graph

231 Commits

Author SHA1 Message Date
Junio C Hamano
1c88a6d174 Sync with 1.7.11.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11 11:23:54 -07:00
Junio C Hamano
ee7a83f631 Merge branch 'sz/submodule-force-update' into maint-1.7.11
* sz/submodule-force-update:
  Make 'git submodule update --force' always check out submodules.
2012-09-11 11:10:17 -07:00
Junio C Hamano
81dbbf7240 Merge branch 'sz/submodule-force-update'
"git submodule update --force" used to leave the working tree of the
submodule intact when there were local changes.  It is more intiutive
to make "--force" a sign to run "checkout -f" to overwrite them.

* sz/submodule-force-update:
  Make 'git submodule update --force' always check out submodules.
2012-09-03 15:54:18 -07:00
Junio C Hamano
1c0fa76be7 Merge branch 'hv/submodule-path-unmatch'
* hv/submodule-path-unmatch:
  Let submodule command exit with error status if path does not exist
2012-08-29 14:50:15 -07:00
Stefan Zager
01d4721565 Make 'git submodule update --force' always check out submodules.
Currently, it will only do a checkout if the sha1 registered in the containing
repository doesn't match the HEAD of the submodule, regardless of whether the
submodule is dirty.  As discussed on the mailing list, the '--force' flag is a
strong indicator that the state of the submodule is suspect, and should be reset
to HEAD.

Signed-off-by: Stefan Zager <szager@google.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-24 09:00:43 -07:00
Heiko Voigt
be9d0a3a4c Let submodule command exit with error status if path does not exist
Various subcommands of the "git submodule" command exited with 0
status even though the path given by the user did not exist.

The reason behind that was that they all pipe the output of
module_list into the while loop which then does the action on the
paths specified by the commandline. Since the exit code of the
command on the upstream side of the pipe is ignored by the shell,
the status code of "ls-files --error-unmatch" nor "module_list" was
not propagated.

In case ls-files returns with an error code, we write a special
string that is not possible in non error situations, and no other
output, so that the downstream can detect the error and die with an
error code.

The error message that there is an unmatched pathspec comes through
stderr directly from ls-files. So the user still gets a hint whats going
on.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-14 14:00:17 -07:00
Junio C Hamano
5fe1484a9b Merge branch 'jx/i18n-1.7.11'
Add i18n support for scripted Porcelains, and mark strings in
merge(-recursive), am, and rebase for i18n.

* jx/i18n-1.7.11:
  i18n: merge-recursive: mark strings for translation
  Remove dead code which contains bad gettext block
  i18n: am: mark more strings for translation
  rebase: remove obsolete and unused LONG_USAGE which breaks xgettext
  i18n: Rewrite gettext messages start with dash
  i18n: rebase: mark messages for translation
  i18n: New keywords for xgettext extraction from sh
2012-07-31 09:41:52 -07:00
Junio C Hamano
8ba105dda8 Merge branch 'jl/maint-1.7.10-recurse-submodules-with-symlink' into maint
When "git submodule add" clones a submodule repository, it can get
confused where to store the resulting submodule repository in the
superproject's .git/ directory when there is a symbolic link in the
path to the current directory.

* jl/maint-1.7.10-recurse-submodules-with-symlink:
  submodules: don't stumble over symbolic links when cloning recursively
2012-07-30 13:04:18 -07:00
Jiang Xin
465d6a00e9 i18n: Rewrite gettext messages start with dash
Gettext message in a shell script should not start with '-', one
workaround is adding '--' between gettext and the message, like:

    gettext -- "--exec option ..."

But due to a bug in the xgettext extraction, xgettext can not
extract the actual message for this case. Rewriting the message
is a simpler and better solution.

Reported-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-26 22:33:37 -07:00
Daniel Graña
be8779f7ac git-submodule: work with GIT_DIR/GIT_WORK_TREE
The combination of GIT_DIR and GIT_WORK_TREE can be used to manage
files in one directory hierarchy while keeping the repository that
keeps track of them outside the directory hierarchy.  For example:

    git init --bare /path/to/there
    alias dotfiles="GIT_DIR=/path/to/there GIT_WORK_TREE=/path/to/here git"

    cd /path/to/here
    dotfiles add file
    dotfiles commit -a -m "add /path/to/here/file"
    ...

lets you manage files under /path/to/here/ in the repository located
at /path/to/there.

git-submodule however fails to add submodules, as it is confused by
GIT_DIR and GIT_WORK_TREE environment variables when it tries to
work in the submodule, like so:

    dotfiles submodule add http://path.to/submodule
    fatal: working tree '/path/to/here' already exists.

Simply unsetting the environment where the command works on the
submodule is sufficient to fix this, as it has set things up so
that GIT_DIR and GIT_WORK_TREE do not even have to point at the
repository and the working tree of the submodule.

Signed-off-by: Daniel Graña <dangra@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-25 11:33:24 -07:00
Junio C Hamano
15b3c82cbb Merge branch 'jl/maint-1.7.10-recurse-submodules-with-symlink'
When "git submodule add" clones a submodule repository, it can get
confused where to store the resulting submodule repository in the
superproject's .git/ directory when there is a symbolic link in the
path to the current directory.

* jl/maint-1.7.10-recurse-submodules-with-symlink:
  submodules: don't stumble over symbolic links when cloning recursively
2012-07-22 12:55:48 -07:00
Jens Lehmann
6eafa6d096 submodules: don't stumble over symbolic links when cloning recursively
Since 69c3051 (submodules: refactor computation of relative gitdir path)
cloning a submodule recursively fails for nested submodules when a
symbolic link is part of the path to the work tree of the superproject.

This happens when module_clone() tries to find the relative paths between
the work tree and the git dir. When a symbolic link in current $PWD points
to a directory that is at a different level, then determining the number
of "../" needed to traverse to the superproject's work tree leads to a
wrong result.

As there is no portable way to say "pwd -P", use cd_to_toplevel to remove
the link from $PWD, which fixes this problem.

A test for this issue has been added to t7406.

Reported-by: Bob Halley <halley@play-bow.org>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-12 11:14:40 -07:00
Junio C Hamano
a3fbb2350d Merge branch 'js/submodule-relative'
Teach "git submodule" deal with nested submodule structure where a
module is contained within a module whose origin is specified as a
relative URL to its superproject's origin.
2012-06-28 15:20:55 -07:00
Michał Górny
4c8a9db6f7 git-submodule.sh: fix filename in comment.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25 11:09:35 -07:00
Jon Seymour
758615e251 submodule: fix handling of superproject origin URLs like foo, ./foo and ./foo/bar
Currently git submodule init and git submodule sync fail with an error
if the superproject origin URL is of the form foo but succeed if the
superproject origin URL is of the form ./foo or ./foo/bar or foo/bar.

This change makes handling of the foo case behave like the handling
of the ./foo case and also ensures that superfluous leading and
embedded ./'s are removed from the resulting derived URLs.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-06 11:43:55 -07:00
Jon Seymour
967b2c6673 submodule: fix sync handling of some relative superproject origin URLs
When the origin URL of the superproject is itself relative, git submodule sync
configures the remote.origin.url configuration property of the submodule
with a path that is relative to the work tree of the superproject
rather than the work tree of the submodule.

To fix this an 'up_path' that navigates from the work tree of the submodule
to the work tree of the superproject needs to be prepended to the URL
otherwise calculated.

Correct handling of superproject origin URLs like foo, ./foo and ./foo/bar is
left to a subsequent patch since an additional change is required to handle
these cases.

The documentation of resolve_relative_url() is expanded to give a more thorough
description of the function's objective.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-06 11:40:59 -07:00
Jens Lehmann
c1c259e225 submodules: print "registered for path" message only once
Since 2cd9de3e (submodule add: always initialize .git/config entry) the
message "Submodule '\$name' (\$url) registered for path '\$sm_path'" is
printed every time cmd_init() is called, e.g. each time "git submodule
update" is used with the --init option.

This was not intended and leads to bogus output which can confuse users
and build systems. Apart from that the $url variable was not set after the
first run which did the actual initialization and only "()" was printed
in subsequent runs where "($url)" was meant to inform the user about the
upstream repo.

Fix that by moving the say command in question into the if block where the
url is initialized, restoring the behavior that was in place before the
2cd9de3e commit. While at it also remove the comment which still describes
the logic used before 2cd9de3e and add a comment about how things work now.

Reported-by: Nicolas Viennot and Sid Nair <nicolas@viennot.com>
Reported-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-29 13:52:23 -07:00
Junio C Hamano
8ea07808c1 Merge branch 'rj/submodule-mswin-path'
By Ramsay Jones
* rj/submodule-mswin-path:
  git-submodule.sh: Don't use $path variable in eval_gettext string
2012-04-23 13:01:49 -07:00
Ramsay Jones
64394e3ae9 git-submodule.sh: Don't use $path variable in eval_gettext string
The eval_gettext (and eval_gettextln) i18n shell functions call
git-sh-i18n--envsubst to process the variable references in the
string parameter. Unfortunately, environment variables are case
insensitive on windows, which leads to failure on cygwin when
eval_gettext exports $path.

Commit df599e9 (Windows: teach getenv to do a case-sensitive search,
06-06-2011) attempts to solve this problem on MinGW by overriding
the system getenv() function to allow git-sh-i18n--envsubst to read
$path rather than $PATH from the environment. However, this commit
does not address cygwin at all and, furthermore, does not fix all
problems on MinGW.

In particular, when executing test #38 in t7400-submodule-basic.sh,
an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog
pops up saying that the application "failed to start because
libiconv2.dll was not found." After studying the voluminous trace
output from the process monitor, it is clear that the system is
attempting to use $path, rather than $PATH, to search for the DLL
file. (Note that, after dismissing the dialog, the test passes
anyway!)

As an alternative, we finesse the problem by renaming the $path
variable to $sm_path (submodule path). This fixes the problem on
MinGW along with all test failures on cygwin (t7400.{7,32,34},
t7406.3 and t7407.{2,6}). We note that the foreach subcommand
provides $path to user scripts (ie it is part of the API), so we
can't simply rename it to $sm_path.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-18 13:05:33 -07:00
Ben Walton
c5bc42b9b7 Avoid bug in Solaris xpg4/sed as used in submodule
The sed provided by Solaris in /usr/xpg4/bin has a bug whereby an
unanchored regex using * for zero or more repetitions sees two
separate matches fed to the substitution engine in some cases.

This is evidenced by:

$ for sed in /usr/xpg4/bin/sed /usr/bin/sed /opt/csw/gnu/sed; do \
echo 'ab' | $sed -e 's|[a]*|X|g'; \
done
XXbX
XbX
XbX

This bug was triggered during a git submodule clone operation as
exercised in the setup stage of t5526-fetch-submodules when using the
default SANE_TOOL_PATH for Solaris.  It led to paths such as
..../.. being used in the submodule .git gitdir reference.

Using the expression 's|\([^/]*\(/*\)\)|..\2|g' provides the desired
result with all three three tested sed implementations but is harder
to read.  As we do not need to handle fully qualified paths though,
the expression could actually be [^/]+ which isn't properly handled
either.  Instead, use [^/][^/]*, as suggested by Andreas Schwab, which
works on all three tested sed implementations.

The new expression is semantically different than the original one.
It will not place a leading '..' on a fully qualified path as the
original expression did.  All of the paths being passed through this
regex are relative and did not rely on this behaviour so it's a safe
change.

Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-09 14:49:32 -07:00
Johannes Sixt
4dce7d9b40 submodules: fix ambiguous absolute paths under Windows
Under Windows the "git rev-parse --git-dir" and "pwd" commands may return
either drive-letter-colon or POSIX style paths. This makes module_clone()
behave badly because it expects absolute paths to always start with a '/'.

Fix that by always converting the "c:/" notation into "/c/" when computing
the relative paths from gitdir to the submodule work tree and back.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04 21:22:46 -08:00
Jens Lehmann
69c3051780 submodules: refactor computation of relative gitdir path
In module_clone() the rel_gitdir variable was computed differently when
"git rev-parse --git-dir" returned a relative path than when it returned
an absolute path. This is not optimal, as different code paths are used
depending on the return value of that command.

Fix that by reusing the differing path components computed for setting the
core.worktree config setting, which leaves a single code path for setting
both instead of having three and makes the code much shorter.

This also fixes the bug that in the computation of how many directories
have to be traversed up to hit the root directory of the submodule the
name of the submodule was used where the path should have been used. This
lead to problems after renaming submodules into another directory level.

Even though the "(cd $somewhere && pwd)" approach breaks the flexibility
of symlinks, that is no issue here as we have to have one relative path
pointing from the work tree to the gitdir and another pointing back, which
will never work anyway when a symlink along one of those paths is changed
because the directory it points to was moved.

Also add a test moving a submodule into a deeper directory to catch any
future breakage here and to document what has to be done when a submodule
needs to be moved until git mv learns to do that. Simply moving it to the
new location doesn't work, as the core.worktree and possibly the gitfile
setting too will be wrong. So it has to be removed from filesystem and
index, then the new location has to be added into the index and the
.gitmodules file has to be updated. After that a git submodule update will
check out the submodule at the new location.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04 21:22:35 -08:00
Jens Lehmann
d75219b4a8 submodules: always use a relative path from gitdir to work tree
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. To make that work the git directory has
the core.worktree configuration set in its config file to point back to
the work tree.

That core.worktree is an absolute path set by the initial clone of the
submodule. A relative path is preferable here because it allows the
superproject to be moved around without invalidating that setting, so
compute and set that relative path after cloning or reactivating the
submodule.

This also fixes a bug when moving a submodule around inside the
superproject, as the current code forgot to update the setting to the new
submodule work tree location.

Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident and that moving a superproject won't break submodules.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04 21:20:27 -08:00
Jens Lehmann
ea115a0d43 submodules: always use a relative path to gitdir
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. When the submodule git directory needs
to be cloned because it is not found in .git/modules/<name> the clone
command will write an absolute path into the gitfile. When no clone is
necessary the git directory will be reactivated by the git-submodule.sh
script by writing a relative path into the gitfile.

This is inconsistent, as the behavior depends on the submodule having been
cloned before into the .git/modules of the superproject. A relative path
is preferable here because it allows the superproject to be moved around
without invalidating the gitfile. We do that by always writing the
relative path into the gitfile, which overwrites the absolute path the
clone command may have written there.

This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
is to use a relative path in core.worktree too.

Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident.

While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.

Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04 21:19:41 -08:00
Jens Lehmann
1017c1abcb submodule add: fix breakage when re-adding a deep submodule
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there.

When the same submodule is added on a branch where it wasn't present so
far (it is not found in the .gitmodules file), the name is not initialized
from the path as it should. This leads to a wrong path entered in the
gitfile when the .git/modules/<name> directory is found, as this happily
uses the - now empty - name. It then always points only a single directory
up, even if we have a path deeper in the directory hierarchy.

Fix that by initializing the name of the submodule early in module_clone()
if module_name() returned an empty name and add a test to catch that bug.

Reported-by: Jehan Bing <jehan@orb.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-24 14:18:18 -08:00
Junio C Hamano
0b26d1e8b2 Merge branch 'tc/submodule-clone-name-detection'
* tc/submodule-clone-name-detection:
  submodule::module_clone(): silence die() message from module_name()
  submodule: whitespace fix
2011-10-26 16:16:32 -07:00
Tay Ray Chuan
9e76d4a834 submodule::module_clone(): silence die() message from module_name()
The die() message that may occur in module_name() is not really relevant
to the user when called from module_clone(); the latter handles the
"failure" (no submodule mapping) anyway.

Analysis of other callsites is left to future work.

Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21 10:02:02 -07:00
Tay Ray Chuan
1e42258acd submodule: whitespace fix
Replace SPs with TAB.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21 10:01:50 -07:00
Junio C Hamano
efc5fb6a77 Merge branch 'fg/submodule-git-file-git-dir'
* fg/submodule-git-file-git-dir:
  Move git-dir for submodules
  rev-parse: add option --resolve-git-dir <path>

Conflicts:
	cache.h
	git-submodule.sh
2011-10-10 15:56:17 -07:00
Junio C Hamano
957450054c Merge branch 'js/i18n-scripts'
* js/i18n-scripts:
  submodule: take advantage of gettextln and eval_gettextln.
  stash: take advantage of eval_gettextln
  pull: take advantage of eval_gettextln
  git-am: take advantage of gettextln and eval_gettextln.
  gettext: add gettextln, eval_gettextln to encode common idiom
2011-08-25 16:00:16 -07:00
Fredrik Gustafsson
501770e1bb Move git-dir for submodules
Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of
the superproject. This is a step towards being able to delete submodule
directories without loosing the information from their .git directory
as that is now stored outside the submodules work tree.

This is done relying on the already existent .git-file functionality.
When adding or updating a submodule whose git directory is found under
$GIT_DIR/modules/[name_of_submodule], don't clone it again but simply
point the .git-file to it and remove the now stale index file from it.
The index will be recreated by the following checkout.

This patch will not affect already cloned submodules at all.

Tests that rely on .git being a directory have been fixed.

Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22 21:03:38 -07:00
Junio C Hamano
86c9cd8d25 Merge branch 'jl/submodule-update-quiet'
* jl/submodule-update-quiet:
  submodule: update and add must honor --quiet flag
2011-08-08 12:33:34 -07:00
Jon Seymour
6ff875c52a submodule: take advantage of gettextln and eval_gettextln.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-08 12:05:27 -07:00
Jens Lehmann
7e60407f7a submodule: update and add must honor --quiet flag
When using the --quiet flag "git submodule update" and "git submodule add"
didn't behave as the documentation stated. They printed progress output
from the clone, even though they should only print error messages.

Fix that by passing the -q flag to git clone in module_clone() when the
GIT_QUIET variable is set. Two tests in t7400 have been modified to test
that behavior.

Reported-by: Daniel Holtmann-Rice <flyingtabmow@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-28 12:48:26 -07:00
Junio C Hamano
c56dce3b81 Merge branch 'jl/submodule-add-relurl-wo-upstream'
* jl/submodule-add-relurl-wo-upstream:
  submodule add: clean up duplicated code
  submodule add: allow relative repository path even when no url is set
  submodule add: test failure when url is not configured in superproject

Conflicts:
	git-submodule.sh
2011-07-22 14:24:35 -07:00
Junio C Hamano
0591c0a5be Merge branch 'jc/submodule-sync-no-auto-vivify'
* jc/submodule-sync-no-auto-vivify:
  submodule add: always initialize .git/config entry
  submodule sync: do not auto-vivify uninteresting submodule

Conflicts:
	git-submodule.sh
2011-07-19 09:45:37 -07:00
Junio C Hamano
13ac90a478 Merge branch 'bc/submodule-foreach-stdin-fix-1.7.4'
* bc/submodule-foreach-stdin-fix-1.7.4:
  git-submodule.sh: preserve stdin for the command spawned by foreach
  t/t7407: demonstrate that the command called by 'submodule foreach' loses stdin

Conflicts:
	git-submodule.sh
2011-07-13 14:31:37 -07:00
Junio C Hamano
ff968f03e6 Merge branch 'fg/submodule-keep-updating'
* fg/submodule-keep-updating:
  git-submodule.sh: clarify the "should we die now" logic
  submodule update: continue when a checkout fails
  git-sh-setup: add die_with_status

Conflicts:
	git-submodule.sh
2011-07-13 14:31:35 -07:00
Brandon Casey
4dca1aa650 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-29 18:25:49 -07:00
Junio C Hamano
61f44720a9 Merge branch 'ab/i18n-scripts' into next
* ab/i18n-scripts: (48 commits)
  i18n: git-bisect bisect_next_check "You need to" message
  i18n: git-bisect [Y/n] messages
  i18n: git-bisect bisect_replay + $1 messages
  i18n: git-bisect bisect_reset + $1 messages
  i18n: git-bisect bisect_run + $@ messages
  i18n: git-bisect die + eval_gettext messages
  i18n: git-bisect die + gettext messages
  i18n: git-bisect echo + eval_gettext message
  i18n: git-bisect echo + gettext messages
  i18n: git-bisect gettext + echo message
  i18n: git-bisect add git-sh-i18n
  i18n: git-stash drop_stash say/die messages
  i18n: git-stash "unknown option" message
  i18n: git-stash die + eval_gettext $1 messages
  i18n: git-stash die + eval_gettext $* messages
  i18n: git-stash die + eval_gettext messages
  i18n: git-stash die + gettext messages
  i18n: git-stash say + gettext messages
  i18n: git-stash echo + gettext message
  i18n: git-stash add git-sh-i18n
  ...
2011-06-29 17:09:27 -07:00
Jens Lehmann
2cd9de3e18 submodule add: always initialize .git/config entry
When "git submodule add $path" is run to add a subdirectory $path to the
superproject, and $path is already the top of the working tree of the
submodule repository, the command created submodule.$path.url entry in the
configuration file in the superproject. However, when adding a repository
$URL that is outside the respository of the superproject to $path that
does not exist (yet) with "git submodule add $URL $path", the command
forgot to set it up.

The user is expressing the interest in the submodule and wants to keep a
checkout, the "submodule add" command should consistently set up the
submodule.$path.url entry in either case.

As a result "git submodule init" can't simply skip the initialization of
those submodules for which it finds an url entry in the git./config
anymore. That lead to problems when adding a submodule (which now sets the
url), add the "update" setting to .gitmodules and expect init to copy that
into .git/config like it is done in t7406. So change init to only then
copy the "url" and "update" entries when they don't exist yet in the
.git/config and do nothing otherwise.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-26 13:15:21 -07:00
Junio C Hamano
ccee60862b submodule sync: do not auto-vivify uninteresting submodule
Earlier 33f072f (submodule sync: Update "submodule.<name>.url" for empty
directories, 2010-10-08) attempted to fix a bug where "git submodule sync"
command does not update the URL if the current superproject does not have
a checkout of the submodule.

However, it did so by unconditionally registering submodule.$name.url to
every submodule in the project, even the ones that the user has never
showed interest in at all by running 'git submodule init' command. This
caused subsequent 'git submodule update' to start cloning/updating submodules
that are not interesting to the user at all.

Update the code so that the URL is updated from the .gitmodules file only
for submodules that already have submodule.$name.url entries, i.e. the
ones the user has showed interested in having a checkout.

Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-26 13:06:08 -07:00
Junio C Hamano
877449c136 git-submodule.sh: clarify the "should we die now" logic
Earlier the decision to stop or continue was made on the $action variable
that was set by inspecting $update_module variable. The former is a
redundant variable and will be removed in another topic.

Decide upon inspecting $update_module if a failure should cascade up to
cause us immediately stop, and use a variable that means just that, to
clarify the logic.

Incidentally this also makes the merge with the other topic slightly
easier and cleaner to understand.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-13 12:18:29 -07:00
Fredrik Gustafsson
15ffb7cde4 submodule update: continue when a checkout fails
"git submodule update" stops at the first error and gives control
back to the user. Only after the user fixes the problematic
submodule and runs "git submodule update" again, the second error
is found. And the user needs to repeat until all the problems are
found and fixed one by one. This is tedious.

Instead, the command can remember which submodules it had trouble with,
continue updating the ones it can, and report which ones had errors at
the end. The user can run "git submodule update", find all the ones that
need minor fixing (e.g. working tree was dirty) to fix them in a single
pass. Then another "git submodule update" can be run to update all.

Note that the problematic submodules are skipped only when they are to
be integrated with a safer value of submodule.<name>.update option,
namely "checkout". Fixing a failure in a submodule that uses "rebase" or
"merge" may need an involved conflict resolution by the user, and
leaving too many submodules in states that need resolution would not
reduce the mental burden on the user.

Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-13 11:24:48 -07:00
Jens Lehmann
f22a17e8da submodule add: clean up duplicated code
In cmd_add() the switch statement used to resolve a relative url was
present twice. Remove the second one and use the realrepo variable set
by the first one (lines 194 ff.) instead.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-06 13:46:36 -07:00
Jens Lehmann
4d68932004 submodule add: allow relative repository path even when no url is set
Adding a submodule with a relative repository path did only succeed when
the superproject's default remote was set. But when that is unset, the
superproject is its own authoritative upstream, so lets use its working
directory as upstream instead.

This allows users to set up a new superpoject where the submodules urls
are configured relative to the superproject's upstream while its default
remote can be configured later.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-06 13:46:36 -07:00
Junio C Hamano
fb674d7671 Merge branch 'maint'
* maint:
  git-submodule.sh: separate parens by a space to avoid confusing some shells
  Documentation/technical/api-diff.txt: correct name of diff_unmerge()
  read_gitfile_gently: use ssize_t to hold read result
  remove tests of always-false condition
  rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-30 00:09:55 -07:00
Brandon Casey
f5799e05c0 git-submodule.sh: separate parens by a space to avoid confusing some shells
Some shells interpret '(( ))' according to the rules for arithmetic
expansion.  This may not follow POSIX, but is prevalent in commonly used
shells.  Bash does not have a problem with this particular instance of
'((', likely because it is not followed by a '))', but the public domain
ksh does, and so does ksh on IRIX 6.5.

So, add a space between the parenthesis to avoid confusing these shells.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26 15:04:05 -07:00
Ævar Arnfjörð Bjarmason
b3e7344964 i18n: git-submodule "blob" and "submodule" messages
Gettextize the words "blob" and "submodule", which will be
interpolated in a message emitted by git-submodule. This is
explicitly tested for so we need to skip a portion of a test with
test_i18ncmp.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
1c2ef66f63 i18n: git-submodule "path not initialized" message
Gettextize the "Submodule path '$path' not initialized" message. This
is explicitly tested for so we need to skip a portion of a test with
test_i18grep.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
3a4c3ed7e8 i18n: git-submodule "[...] path is ignored" message
Gettextize the "The following path is ignored" message. This is
explicitly tested for so we need to skip a portion of a test with
test_i18ncmp.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
490b6d5749 i18n: git-submodule "Entering [...]" message
Gettextize the "Entering [...]" message. This is explicitly tested for
so we need to skip a portion of a test with test_i18ncmp.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
f62f8212e1 i18n: git-submodule $errmsg messages
Gettextize warning messages stored in the $errmsg variable using
eval_gettext interpolation. This is explicitly tested for so we
need to skip a portion of a test with test_i18ncmp.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
165119e9e6 i18n: git-submodule "Submodule change[...]" messages
Gettextize the "Submodules changed but not updated" and "Submodule
changes to be committed" messages. This is explicitly tested for so we
need to skip a portion of a test with test_i18ncmp.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
b9b9c22f6d i18n: git-submodule "cached cannot be used" message
Gettextize the "--cached cannot be used with --files" message. Since
this message starts with "--" we have to pass "--" as the first
argument. This works with both GNU gettext 0.18.1 (as expected), and
the gettext(1) on Solaris 10.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
ee653c89ff i18n: git-submodule $update_module say + die messages
Gettextize $update_module say and die messages. These messages needed
to be split up to make them translatable.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:16 -07:00
Ævar Arnfjörð Bjarmason
497ee87245 i18n: git-submodule die + eval_gettext messages
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:15 -07:00
Ævar Arnfjörð Bjarmason
8f3f2c44c5 i18n: git-submodule say + eval_gettext messages
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:15 -07:00
Ævar Arnfjörð Bjarmason
dc2204fe32 i18n: git-submodule echo + eval_gettext messages
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:15 -07:00
Ævar Arnfjörð Bjarmason
d0ad825110 i18n: git-submodule add git-sh-i18n
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 11:57:15 -07:00
Junio C Hamano
0d405d72f5 Merge branch 'nm/submodule-update-force'
* nm/submodule-update-force:
  submodule: Add --force option for git submodule update

Conflicts:
	t/t7406-submodule-update.sh
2011-05-02 15:58:36 -07:00
Junio C Hamano
2071fb015b Merge branch 'jl/submodule-fetch-on-demand'
* jl/submodule-fetch-on-demand:
  fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
  submodule update: Don't fetch when the submodule commit is already present
  fetch/pull: Don't recurse into a submodule when commits are already present
  Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
  config: teach the fetch.recurseSubmodules option the 'on-demand' value
  fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
  fetch/pull: recurse into submodules when necessary

Conflicts:
	builtin/fetch.c
	submodule.c
2011-04-04 15:02:01 -07:00
Nicolas Morey-Chaisemartin
9db31bdf5c submodule: Add --force option for git submodule update
By default git submodule update runs a simple checkout on submodules that
are not up-to-date. If the submodules contains modified or untracked
files, the command may exit sanely with an error:

  $ git submodule update
  error: Your local changes to the following files would be overwritten by
  checkout:
	  file
  Please, commit your changes or stash them before you can switch branches.
  Aborting
  Unable to checkout '1b69c6e55606b48d3284a3a9efe4b58bfb7e8c9e' in
  submodule path 'test1'

In order to reset a whole git submodule tree, a user has to run first 'git
submodule foreach --recursive git checkout -f' and then run 'git submodule
update'.

This patch adds a --force option for the update command (only used for
submodules without --rebase or --merge options). It passes the --force
option to git checkout which will throw away the local changes.

Signed-off-by: Nicolas Morey-Chaisemartin <nmorey@kalray.eu>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04 10:50:50 -07:00
Nicolas Morey-Chaisemartin
313ee0d69f 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 17:34:08 -07:00
Jens Lehmann
e5f522d610 submodule update: Don't fetch when the submodule commit is already present
If the commit to be checked out on "git submodule update" has already been
fetched in the submodule there is no need to run "git fetch" again. Since
"git fetch" recently learned recursion (and the new on-demand mode to
fetch commits recorded in the superproject is enabled by default) this
will happen pretty often, thereby making the unconditional fetch during
"git submodule update" unnecessary.

If the commit is not present in the submodule (e.g. the user disabled the
fetch on-demand mode) the fetch will be run as before.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 13:10:35 -08:00
Spencer E. Olson
1b4735d9f3 submodule: no [--merge|--rebase] when newly cloned
"git submodule update" can be run with either the "--merge" or "--rebase"
option, or submodule.<name>.update configuration variable can be set to
"merge" or "rebase, to cause local work to get integrated when updating
the submodule.

When a submodule is newly cloned, however, it does not have a check out
when a rebase or merge is attempted, leading to a failure.  For newly
cloned submodules, simply check out the appropriate revision.  There is no
local work to integrate with for them.

Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-17 12:19:18 -08:00
Junio C Hamano
4f93fc745a Merge branch 'tr/submodule-relative-scp-url'
* tr/submodule-relative-scp-url:
  submodule: fix relative url parsing for scp-style origin
2011-01-13 11:34:39 -08:00
Thomas Rast
ea640cc691 submodule: fix relative url parsing for scp-style origin
The function resolve_relative_url was not prepared to deal with an
scp-style origin 'user@host:path' in the case where 'path' is only a
single component.  Fix this by extending the logic that strips one
path component from the $remoteurl.

Also add tests for both styles of URLs.

Noticed-by: Jeffrey Phillips Freeman <jeffrey.freeman@syncleus.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-10 09:10:54 -08:00
Junio C Hamano
7eaf4af426 Merge branch 'jn/submodule-b-current'
* jn/submodule-b-current:
  git submodule: Remove now obsolete tests before cloning a repo
  git submodule -b ... of current HEAD fails
2010-12-16 12:49:22 -08:00
Jens Lehmann
69e7236c6d git submodule: Remove now obsolete tests before cloning a repo
Since 55892d23 "git clone" itself checks that the destination path is not
a file but an empty directory if it exists, so there is no need anymore
for module_clone() to check that too.

Two tests have been added to test the behavior of "git submodule add" when
path is a file or a directory (A subshell had to be added to the former
last test to stay in the right directory).

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-06 16:42:07 -08:00
Jonathan Nieder
502dc5b663 git submodule -b ... of current HEAD fails
git submodule add -b $branch $repository

fails when HEAD already points to $branch in $repository.

Reported-by: Klaus Ethgen <Klaus@Ethgen.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-06 16:41:44 -08:00
Junio C Hamano
aef5c38b59 Merge branch 'kb/maint-submodule-savearg'
* kb/maint-submodule-savearg:
  submodule: only preserve flags across recursive status/update invocations
  submodule: preserve all arguments exactly when recursing
2010-11-17 15:02:12 -08:00
Kevin Ballard
98dbe63dbc submodule: only preserve flags across recursive status/update invocations
Recursive invocations of submodule update/status preserve all arguments,
so executing

        git submodule update --recursive -- foo

attempts to recursively update a submodule named "foo".

Naturally, this fails as one cannot have an infinitely-deep stack of
submodules each containing a submodule named "foo". The desired behavior
is instead to update foo and then recursively update all submodules
inside of foo.

This commit accomplishes that by only saving the flags for use in the
recursive invocation.

Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 12:51:28 -07:00
Kevin Ballard
a7eff1a87a submodule: preserve all arguments exactly when recursing
Shell variables only hold strings, not lists of parameters,
so $orig_args after

        orig_args="$@"

fails to remember where each parameter starts and ends, if
some include whitespace.  So

        git submodule update \
                --reference='/var/lib/common objects.git' \
                --recursive --init

becomes

        git submodule update --reference=/var/lib/common \
                objects.git --recursive --init

in the inner repositories.  Use "git rev-parse --sq-quote" to
save parameters in quoted form ready for evaluation by the
shell, avoiding this problem.

Helped-By: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 12:51:26 -07:00
Andreas Köhler
33f072f891 submodule sync: Update "submodule.<name>.url" for empty directories
If a submodule directory has not been filled by "git submodule update"
yet, then "git submodule sync" must still update the super-project's
configuration for submodule.<name>.url.

This situation occurs when switching between branches with a module from
different urls and other branches without the submodule.

Signed-off-by: Andreas Köhler <andi5.py@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13 18:31:45 -07:00
David Aguilar
0b9dca434f submodule sync: Update "submodule.<name>.url"
When "git submodule sync" synchronizes the repository URLs
it only updates submodules' .git/config.  However, the old
URLs still exist in the super-project's .git/config.

Update the super-project's configuration so that commands
such as "git submodule update" use the URLs from .gitmodules.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18 13:54:30 -07:00
Jens Lehmann
d27b876b28 git submodule add: Require the new --force option to add ignored paths
To make the behavior of "git submodule add" more consistent with "git add"
ignored submodule paths should not be silently added when they match an
entry in a .gitignore file. To be able to override that default behavior
in the same way as we can do that for "git add", the new option "--force"
is introduced.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-19 11:10:43 -07:00
Ævar Arnfjörð Bjarmason
31991b0260 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 11:53:59 -07:00
Junio C Hamano
a76b2084fb Merge branch 'jl/status-ignore-submodules'
* jl/status-ignore-submodules:
  Add the option "--ignore-submodules" to "git status"
  git submodule: ignore dirty submodules for summary and status

Conflicts:
	builtin/commit.c
	t/t7508-status.sh
	wt-status.c
	wt-status.h
2010-06-30 11:55:39 -07:00
Jens Lehmann
18076502cb git submodule: ignore dirty submodules for summary and status
The summary and status commands only care about submodule commits, so it is
rather pointless that they check for dirty work trees. This saves the time
needed to scan the submodules work tree. Even "git status" profits from these
savings when the status.submodulesummary config option is set, as this lead to
traversing the submodule work trees twice, once for status and once again for
the submodule summary. And if the submodule was just dirty, submodule summary
produced rather meaningless output anyway:

 * sub 1234567...1234567 (0):

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25 11:12:27 -07:00
Ævar Arnfjörð Bjarmason
f030c96d86 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-25 09:04:24 -07:00
Junio C Hamano
72d9b222a9 Merge branch 'sd/log-decorate'
* sd/log-decorate:
  log.decorate: only ignore it under "log --pretty=raw"
  script with rev-list instead of log
  log --pretty/--oneline: ignore log.decorate
  log.decorate: usability fixes
  Add `log.decorate' configuration variable.
  git_config_maybe_bool()

Conflicts:
	builtin/log.c
2010-05-08 22:36:14 -07:00
Junio C Hamano
ddb27a5a6b Merge branch 'maint'
* maint:
  index-pack: fix trivial typo in usage string
  git-submodule.sh: properly initialize shell variables
2010-05-01 20:23:10 -07:00
Gerrit Pape
48bb30331d git-submodule.sh: properly initialize shell variables
git-submodule inherits variables from the environment it is started in,
expects the internal variables init= and recursive= to have an empty
value, but doesn't initialize them appropriately.  Thanks to the
selftests, this can be reproduced through

 init=1 make test
 recursive=1 make test

With this commit the variables are initialized, and the selftests
succeed even if these variables have some values in the environment.

The bug was discovered through the Debian autobuilders
 http://bugs.debian.org/569594

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-01 11:11:52 -07:00
Jeff King
b0e621adfd script with rev-list instead of log
Because log.decorate now shows decorations for --pretty=oneline,
we must explicitly turn it off when scripting. Otherwise,
users with log.decorate set will get cruft like:

  $ git stash
  Saved working directory and index state WIP on master:
    2c1f7f5 (HEAD, master) commit subject

Instead of adding --no-decorate to the log command line,
let's just use the rev-list plumbing interface instead,
which does the right thing.

git-submodule has a similar call. Since it just counts the
commit lines, nothing is broken, but let's switch it, too,
for the sake of consistency and cleanliness.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-08 23:13:48 -07:00
Junio C Hamano
5e4f614742 Merge branch 'jh/maint-submodule-status-in-void'
* jh/maint-submodule-status-in-void:
  git submodule summary: Handle HEAD as argument when on an unborn branch
  submodule summary: do not fail before the first commit
2010-03-24 16:55:37 -07:00
Jens Lehmann
2ea6c2c9ab git submodule summary: Handle HEAD as argument when on an unborn branch
When calling "git submodule summary HEAD" on an unborn branch the output
was empty even when it shouldn't have been ("git submodule summary"
without the HEAD argument prints the expected output since commit
"submodule summary: do not fail before the first commit").

This also fixes "git status" to emit the "Submodule changes to be
committed" section on an unborn branch when used with the
status.submodulesummary config option.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09 23:15:01 -08:00
Junio C Hamano
9317dc4f05 Merge branch 'gb/maint-submodule-env'
* gb/maint-submodule-env:
  is_submodule_modified(): clear environment properly
  submodules: ensure clean environment when operating in a submodule
  shell setup: clear_local_git_env() function
  rev-parse: --local-env-vars option
  Refactor list of of repo-local env vars
2010-03-07 12:47:17 -08:00
Junio C Hamano
14e940d719 submodule summary: do not fail before the first commit
When "git status" collects changes for the index (usually relative to
HEAD), it compares the index with an empty tree when the repository does
not have an initial commit yet.  "git submodule summary" is about asking
what submodule changes would be recorded if a commit is made right now,
and should do the same comparison to report all the added submodules,
instead of punting and being silent.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-03 14:33:22 -08:00
Jeff King
caa9c3cabe submodule summary: do not shift a non-existent positional variable
When "git submodule summary" is run without any argument, we default to
compare the state of index with the HEAD, but tried to shift out $1 that
does not exist (and worse yet, we didn't use it).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-03 14:33:21 -08:00
Giuseppe Bilotta
74ae14199d submodules: ensure clean environment when operating in a submodule
git-submodule used to take care of clearing GIT_DIR whenever it operated
on a submodule index or configuration, but forgot to unset GIT_WORK_TREE
or other repo-local variables. This would lead to failures e.g. when
GIT_WORK_TREE was set.

This only happened in very unusual contexts such as operating on the
main worktree from outside of it, but since "git-gui: set GIT_DIR and
GIT_WORK_TREE after setup" (a9fa11fe5b) such failures could also
be provoked by invoking an external tool such as "git submodule update"
from the Git Gui in a standard setup.

Solve by using the newly introduced clear_local_git_env() shell function
to ensure that all repo-local environment variables are unset.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24 16:24:25 -08:00
Johan Herland
3deea89c5f submodule summary: Don't barf when invoked in an empty repo
When invoking "git submodule summary" in an empty repo (which can be
indirectly done by setting status.submodulesummary = true), it currently
emits an error message (via "git diff-index") since HEAD points to an
unborn branch.

This patch adds handling of the HEAD-points-to-unborn-branch special case,
so that "git submodule summary" no longer emits this error message.

The patch also adds a test case that verifies the fix.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 11:14:04 -08:00
Jens Lehmann
f17a5d3494 git status: Show uncommitted submodule changes too when enabled
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>
2010-01-17 15:55:11 -08:00
Junio C Hamano
ad7ace714d Merge branch 'rs/work-around-grep-opt-insanity'
* rs/work-around-grep-opt-insanity:
  Protect scripted Porcelains from GREP_OPTIONS insanity
  mergetool--lib: simplify guess_merge_tool()

Conflicts:
	git-instaweb.sh
2009-11-25 11:45:07 -08:00
Junio C Hamano
e1622bfcba Protect scripted Porcelains from GREP_OPTIONS insanity
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>
2009-11-23 16:31:07 -08:00
Junio C Hamano
6a09ff14fb Merge branch 'jl/submodule-add-noname'
* jl/submodule-add-noname:
  git submodule add: make the <path> parameter optional
2009-11-20 23:46:07 -08:00
Jim Meyering
0484682ef3 typo fix: Directory `...' exist, ...: s/exist/exists/
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-29 08:30:13 -07:00
Jens Lehmann
1414e5788b git submodule add: make the <path> parameter optional
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>
2009-09-22 12:24:49 -07:00
Junio C Hamano
adc5423531 Merge branch 'jh/submodule-foreach'
* jh/submodule-foreach:
  git clone: Add --recursive to automatically checkout (nested) submodules
  t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
  git submodule status: Add --recursive to recurse into nested submodules
  git submodule update: Introduce --recursive to update nested submodules
  git submodule foreach: Add --recursive to recurse into nested submodules
  git submodule foreach: test access to submodule name as '$name'
  Add selftest for 'git submodule foreach'
  git submodule: Cleanup usage string and add option parsing to cmd_foreach()
  git submodule foreach: Provide access to submodule name, as '$name'

Conflicts:
	Documentation/git-submodule.txt
	git-submodule.sh
2009-08-27 16:59:25 -07:00
Johan Herland
64b19ffedd git submodule status: Add --recursive to recurse into nested submodules
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>
2009-08-18 22:59:58 -07:00