git/Documentation/git-submodule.txt, branch v1.6.3

submodule: add --no-fetch parameter to update command

2009-02-07T08:44:49Z

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 Signed-off-by: Junio C Hamano

Merge branch 'maint' to sync with GIT 1.6.0.6

2008-12-20T03:35:55Z

Signed-off-by: Junio C Hamano

Documentation: fix typos, grammar, asciidoc syntax

2008-12-20T03:10:46Z

Signed-off-by: Markus Heidelberg Signed-off-by: Junio C Hamano

git-submodule: add "sync" command

2008-08-26T05:48:01Z

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 Signed-off-by: Junio C Hamano

git-submodule - Add 'foreach' subcommand

2008-08-17T23:29:22Z

submodule foreach 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 Signed-off-by: Junio C Hamano

Make the DESCRIPTION match ... items in the SYNOPSIS

2008-07-31T04:42:55Z

When the SYNOPSIS says e.g. "...", it is nice if the DESCRIPTION also mentions "..." and says the specified "paths" (note plural) are used for $whatever. This fixes the obvious mismatches. Signed-off-by: Abhijit Menon-Sen Signed-off-by: Junio C Hamano

Documentation/git-submodule.txt: fix doubled word

2008-07-27T21:14:01Z

Signed-off-by: Cesar Eduardo Barros Signed-off-by: Junio C Hamano

Documentation/git-submodule.txt: Further clarify the description

2008-07-19T18:17:43Z

This patch rewrites the general description yet again, first clarifying the high-level concept, mentioning the difference to remotes and using the subtree merge strategy, then getting to the details about tree entries and .gitmodules file. The patch also makes few smallar grammar fixups within the rest of the description and clarifies how does 'init' relate to 'update --init'. Cc: Heikki Orsila Signed-off-by: Petr Baudis Signed-off-by: Junio C Hamano

Documentation/git-submodule.txt: Add Description section

2008-07-17T00:24:32Z

Figuring out how submodules work conceptually is quite a bumpy ride for a newcomer; the user manual helps (if one knows to actually look into it), but the reference documentation should provide good quick intro as well. This patch attempts to do that, with suggestions from Heikki Orsila. Cc: Heikki Orsila Signed-off-by: Petr Baudis Signed-off-by: Junio C Hamano

git-submodule - make "submodule add" more strict, and document it

2008-07-15T06:35:31Z

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 Signed-off-by: Junio C Hamano