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

git submodule add: Remove old docs about implicit -f

2010-07-19T18:11:07Z

git submodule add no longer implicitly adds with --force. Remove references to the old functionality in the documentation. Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Jens Lehmann Signed-off-by: Junio C Hamano

git submodule add: Require the new --force option to add ignored paths

2010-07-19T18:10:43Z

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 Acked-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git submodule: add submodules with git add -f

2010-07-05T18:53:59Z

Change `git submodule add' to add the new submodule 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 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 Signed-off-by: Junio C Hamano

git-submodule foreach: Add $toplevel variable

2010-05-25T16:04:24Z

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

Fix typos in technical documentation.

2010-01-31T18:24:53Z

Signed-off-by: Ralf Wildenhues Signed-off-by: Junio C Hamano

Documentation: spell 'git cmd' without dash throughout

2010-01-10T12:01:28Z

The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.

Documentation: format full commands in typewriter font

2010-01-10T12:01:25Z

Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast

git submodule add: make the parameter optional

2009-09-22T19:24:49Z

When is not given, use the "humanish" part of the source repository instead. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

Merge branch 'jh/submodule-foreach'

2009-08-27T23:59:25Z

* 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

git submodule status: Add --recursive to recurse into nested submodules

2009-08-19T05:59:58Z

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