summaryrefslogtreecommitdiff
path: root/git-submodule.sh
AgeCommit message (Collapse)AuthorFilesLines
2011-01-13Merge branch 'tr/submodule-relative-scp-url'Libravatar Junio C Hamano1-2/+14
* tr/submodule-relative-scp-url: submodule: fix relative url parsing for scp-style origin
2011-01-10submodule: fix relative url parsing for scp-style originLibravatar Thomas Rast1-2/+14
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>
2010-12-16Merge branch 'jn/submodule-b-current'Libravatar Junio C Hamano1-15/+1
* jn/submodule-b-current: git submodule: Remove now obsolete tests before cloning a repo git submodule -b ... of current HEAD fails
2010-12-06git submodule: Remove now obsolete tests before cloning a repoLibravatar Jens Lehmann1-14/+0
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-06git submodule -b ... of current HEAD failsLibravatar Jonathan Nieder1-1/+1
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-11-17Merge branch 'kb/maint-submodule-savearg'Libravatar Junio C Hamano1-12/+9
* kb/maint-submodule-savearg: submodule: only preserve flags across recursive status/update invocations submodule: preserve all arguments exactly when recursing
2010-11-03submodule: only preserve flags across recursive status/update invocationsLibravatar Kevin Ballard1-11/+8
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-03submodule: preserve all arguments exactly when recursingLibravatar Kevin Ballard1-4/+4
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-10-13submodule sync: Update "submodule.<name>.url" for empty directoriesLibravatar Andreas Köhler1-2/+3
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-08-18submodule sync: Update "submodule.<name>.url"Libravatar David Aguilar1-1/+2
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-07-19git submodule add: Require the new --force option to add ignored pathsLibravatar Jens Lehmann1-2/+14
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-05git submodule: add submodules with git add -f <path>Libravatar Ævar Arnfjörð Bjarmason1-2/+2
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-06-30Merge branch 'jl/status-ignore-submodules'Libravatar Junio C Hamano1-3/+3
* 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-25git submodule: ignore dirty submodules for summary and statusLibravatar Jens Lehmann1-3/+3
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-05-25git-submodule foreach: Add $toplevel variableLibravatar Ævar Arnfjörð Bjarmason1-0/+2
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-08Merge branch 'sd/log-decorate'Libravatar Junio C Hamano1-1/+1
* 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-01Merge branch 'maint'Libravatar Junio C Hamano1-0/+2
* maint: index-pack: fix trivial typo in usage string git-submodule.sh: properly initialize shell variables
2010-05-01git-submodule.sh: properly initialize shell variablesLibravatar Gerrit Pape1-0/+2
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-04-08script with rev-list instead of logLibravatar Jeff King1-1/+1
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-03-24Merge branch 'jh/maint-submodule-status-in-void'Libravatar Junio C Hamano1-1/+3
* 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-09git submodule summary: Handle HEAD as argument when on an unborn branchLibravatar Jens Lehmann1-0/+1
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-07Merge branch 'gb/maint-submodule-env'Libravatar Junio C Hamano1-10/+10
* 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-03submodule summary: do not fail before the first commitLibravatar Junio C Hamano1-1/+2
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-03submodule summary: do not shift a non-existent positional variableLibravatar Jeff King1-1/+1
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-02-24submodules: ensure clean environment when operating in a submoduleLibravatar Giuseppe Bilotta1-10/+10
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" (a9fa11fe5bd5978bb) 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-17submodule summary: Don't barf when invoked in an empty repoLibravatar Johan Herland1-2/+5
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-01-17git status: Show uncommitted submodule changes too when enabledLibravatar Jens Lehmann1-1/+5
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>
2009-11-25Merge branch 'rs/work-around-grep-opt-insanity'Libravatar Junio C Hamano1-3/+3
* 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-23Protect scripted Porcelains from GREP_OPTIONS insanityLibravatar Junio C Hamano1-3/+3
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-20Merge branch 'jl/submodule-add-noname'Libravatar Junio C Hamano1-1/+6
* jl/submodule-add-noname: git submodule add: make the <path> parameter optional
2009-09-29typo fix: Directory `...' exist, ...: s/exist/exists/Libravatar Jim Meyering1-1/+1
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-22git submodule add: make the <path> parameter optionalLibravatar Jens Lehmann1-1/+6
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-08-27Merge branch 'jh/submodule-foreach'Libravatar Junio C Hamano1-8/+71
* 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-18git submodule status: Add --recursive to recurse into nested submodulesLibravatar Johan Herland1-4/+20
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-18git submodule update: Introduce --recursive to update nested submodulesLibravatar Johan Herland1-1/+12
In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only update the submodules in the current repo (which is what is currently done by 'git submodule update'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule update' 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-18git submodule foreach: Add --recursive to recurse into nested submodulesLibravatar Johan Herland1-3/+16
In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' 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-18git submodule: Cleanup usage string and add option parsing to cmd_foreach()Libravatar Johan Herland1-3/+25
Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18git submodule foreach: Provide access to submodule name, as '$name'Libravatar Johan Herland1-0/+1
The argument to 'git submodule foreach' already has access to the variables '$path' (the path to the submodule, relative to the superproject) and '$sha1' (the submodule commit recorded by the superproject). This patch adds another variable -- '$name' -- which contains the name of the submodule, as recorded in the superproject's .gitmodules file. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-14git submodule summary: add --files optionLibravatar Jens Lehmann1-3/+16
git submodule summary is providing similar functionality for submodules as git diff-index does for a git project (including the meaning of --cached). But the analogon to git diff-files is missing, so add a --files option to summarize the differences between the index of the super project and the last commit checked out in the working tree of the submodule. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01Merge branch 'sb/quiet-porcelains'Libravatar Junio C Hamano1-18/+6
* 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
2009-06-20Merge branch 'ph/submodule-rebase'Libravatar Junio C Hamano1-1/+10
* ph/submodule-rebase: git-submodule: add support for --merge. Conflicts: Documentation/git-submodule.txt git-submodule.sh
2009-06-18submodule, repack: migrate to git-sh-setup's say()Libravatar Stephen Boyd1-18/+6
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>
2009-06-13Merge branch 'ph/submodule-rebase' (early part)Libravatar Junio C Hamano1-4/+31
* 'ph/submodule-rebase' (early part): Rename submodule.<name>.rebase to submodule.<name>.update git-submodule: add support for --rebase. Conflicts: Documentation/git-submodule.txt git-submodule.sh
2009-06-03git-submodule: add support for --merge.Libravatar Johan Herland1-1/+10
'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>
2009-06-03Rename submodule.<name>.rebase to submodule.<name>.updateLibravatar Johan Herland1-15/+17
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>
2009-05-09Add --reference option to git submodule.Libravatar Michael S. Tsirkin1-4/+34
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>
2009-04-24git-submodule: add support for --rebase.Libravatar Peter Hutterer1-4/+29
'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>
2009-04-18Work around ash "alternate value" expansion bugLibravatar Ben Jackson1-2/+9
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>
2009-04-05git submodule: fix usage lineLibravatar Julien Danjou1-1/+1
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>
2009-03-21Merge branch 'mg/maint-submodule-normalize-path' into maintLibravatar Junio C Hamano1-3/+12
* mg/maint-submodule-normalize-path: git submodule: Fix adding of submodules at paths with ./, .. and // git submodule: Add test cases for git submodule add