user/sven/git.git/git-submodule.sh, branch v1.7.3.5

submodule sync: Update "submodule..url" for empty directories

2010-10-14T01:31:45Z

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

submodule sync: Update "submodule..url"

2010-08-18T20:54:30Z

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 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

Merge branch 'jl/status-ignore-submodules'

2010-06-30T18:55:39Z

* 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

git submodule: ignore dirty submodules for summary and status

2010-06-25T18:12:27Z

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 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

Merge branch 'sd/log-decorate'

2010-05-09T05:36:14Z

* 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

Merge branch 'maint'

2010-05-02T03:23:10Z

* maint: index-pack: fix trivial typo in usage string git-submodule.sh: properly initialize shell variables

git-submodule.sh: properly initialize shell variables

2010-05-01T18:11:52Z

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