git/submodule.h, branch v2.6.2

submodule: allow erroneous values for the fetchRecurseSubmodules option

2015-08-19T18:43:10Z

We should not die when reading the submodule config cache since the user might not be able to get out of that situation when the configuration is part of the history. We should handle this condition later when the value is about to be used. Signed-off-by: Heiko Voigt Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

submodule: use new config API for worktree configurations

2015-08-19T18:43:10Z

We remove the extracted functions and directly parse into and read out of the cache. This allows us to have one unified way of accessing submodule configuration values specific to single submodules. Regardless whether we need to access a configuration from history or from the worktree. Signed-off-by: Heiko Voigt Signed-off-by: Junio C Hamano Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

submodule: implement a config API for lookup of .gitmodules values

2015-08-19T18:43:09Z

In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

rm: delete .gitmodules entry of submodules removed from the work tree

2013-08-06T21:11:00Z

Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule." section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

mv: update the path entry in .gitmodules for moved submodules

2013-08-06T21:10:35Z

Currently using "git mv" on a submodule moves the submodule's work tree in that of the superproject. But the submodule's path setting in .gitmodules is left untouched, which is now inconsistent with the work tree and makes git commands that rely on the proper path -> name mapping (like status and diff) behave strangely. Let "git mv" help here by not only moving the submodule's work tree but also updating the "submodule..path" setting from the .gitmodules file and stage both. This doesn't happen when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already updated the path setting by hand before issuing the "git mv" command (in which case the warning reminds him that mv would have done that for him). Only when .gitmodules is found and contains merge conflicts the mv command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule.c: add .gitmodules staging helper functions

2013-07-30T21:39:56Z

Add the new is_staging_gitmodules_ok() and stage_updated_gitmodules() functions to submodule.c. The first makes it possible for call sites to see if the .gitmodules file did contain any unstaged modifications they would accidentally stage in addition to those they intend to stage themselves. The second function stages all modifications to the .gitmodules file, both will be used by subsequent patches for the mv and rm commands. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

mv: move submodules using a gitfile

2013-07-30T20:52:53Z

When moving a submodule which uses a gitfile to point to the git directory stored in .git/modules/ of the superproject two changes must be made to make the submodule work: the .git file and the core.worktree setting must be adjusted to point from work tree to git directory and back. Achieve that by remembering which submodule uses a gitfile by storing the result of read_gitfile() of each submodule. If that is not NULL the new function connect_work_tree_and_git_dir() is called after renaming the submodule's work tree which updates the two settings to the new values. Extend the man page to inform the user about that feature (and while at it change the description to not talk about a script anymore, as mv is a builtin for quite some time now). Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule: print graph output next to submodule log

2013-04-05T18:28:10Z

When running "git log -p --submodule=log", the submodule log is not indented by the graph output, although all other lines are. Fix this by prepending the current line prefix to each line of the submodule log. Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

submodule: display summary header in bold

2012-11-19T03:18:13Z

Currently, 'git diff --submodule' displays output with a bold diff header for non-submodules. So this part is in bold: diff --git a/file1 b/file1 index 30b2f6c..2638038 100644 --- a/file1 +++ b/file1 For submodules, the header looks like this: Submodule submodule1 012b072..248d0fd: Unfortunately, it's easy to miss in the output because it's not bold. Change this. Signed-off-by: Ramkumar Ramachandra Acked-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jl/submodule-rm'

2012-10-29T08:12:07Z

"git rm submodule" cannot blindly remove a submodule directory as its working tree may have local changes, and worse yet, it may even have its repository embedded in it. Teach it some special cases where it is safe to remove a submodule, specifically, when there is no local changes in the submodule working tree, and its repository is not embedded in its working tree but is elsewhere and uses the gitfile mechanism to point at it. * jl/submodule-rm: submodule: teach rm to remove submodules unless they contain a git directory