git/submodule.c, branch v1.8.2.2

submodule: clarify logic in show_submodule_summary

2013-03-22T21:09:55Z

There are two uses of the "left" and "right" commit variables that make it hard to be sure what values they have (both for the reader, and for gcc, which wrongly complains that they might be used uninitialized). The function starts with a cascading if statement, checking that the input sha1s exist, and finally working up to preparing a revision walk. We only prepare the walk if the cascading conditional did not find any problems, which we check by seeing whether it set the "message" variable or not. It's simpler and more obvious to just add a condition to the end of the cascade. Later, we check the same "message" variable when deciding whether to clear commit marks on the left/right commits; if it is set, we presumably never started the walk. This is wrong, though; we might have started the walk and munged commit flags, only to encounter an error afterwards. We should always clear the flags on left/right if they exist, whether the walk was successful or not. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

submodule: simplify memory handling in config parsing

2013-01-23T20:58:27Z

We keep a strbuf for the name of the submodule, even though we only ever add one string to it. Let's just use xmemdupz instead, which is slightly more efficient and makes it easier to follow what is going on. Unfortunately, we still end up having to deal with some memory ownership issues in some code branches, as we have to allocate the string in order to do a string list lookup, and then only sometimes want to hand ownership of that string over to the string_list. Still, making that explicit in the code (as opposed to sometimes detaching the strbuf, and then always releasing it) makes it a little more obvious what is going on. Signed-off-by: Jeff King Reviewed-by: Jonathan Nieder Acked-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule: use parse_config_key when parsing config

2013-01-23T20:57:50Z

This makes the code a lot simpler to read by dropping a whole bunch of constant offsets. As a bonus, it means we also feed the whole config variable name to our error functions: [before] $ git -c submodule.foo.fetchrecursesubmodules=bogus checkout fatal: bad foo.fetchrecursesubmodules argument: bogus [after] $ git -c submodule.foo.fetchrecursesubmodules=bogus checkout fatal: bad submodule.foo.fetchrecursesubmodules argument: bogus Signed-off-by: Jeff King Reviewed-by: Jonathan Nieder Acked-by: Jens Lehmann 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

submodule: teach rm to remove submodules unless they contain a git directory

2012-09-29T18:33:31Z

Currently using "git rm" on a submodule - populated or not - fails with this error: fatal: git rm: '': Is a directory This made sense in the past as there was no way to remove a submodule without possibly removing unpushed parts of the submodule's history contained in its .git directory too, so erroring out here protected the user from possible loss of data. But submodules cloned with a recent git version do not contain the .git directory anymore, they use a gitfile to point to their git directory which is safely stored inside the superproject's .git directory. The work tree of these submodules can safely be removed without losing history, so let's teach git to do so. Using rm on an unpopulated submodule now removes the empty directory from the work tree and the gitlink from the index. If the submodule's directory is missing from the work tree, it will still be removed from the index. Using rm on a populated submodule using a gitfile will apply the usual checks for work tree modification adapted to submodules (unless forced). For a submodule that means that the HEAD is the same as recorded in the index, no tracked files are modified and no untracked files that aren't ignored are present in the submodules work tree (ignored files are deemed expendable and won't stop a submodule's work tree from being removed). That logic has to be applied in all nested submodules too. Using rm on a submodule which has its .git directory inside the work trees top level directory will just error out like it did before to protect the repository, even when forced. In the future git could either provide a message informing the user to convert the submodule to use a gitfile or even attempt to do the conversion itself, but that is not part of this change. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

Merge branch 'jk/argv-array'

2012-09-11T18:36:18Z

Use argv-array API in "git fetch" implementation. * jk/argv-array: submodule: use argv_array instead of hand-building arrays fetch: use argv_array instead of hand-building arrays argv-array: fix bogus cast when freeing array argv-array: add pop function

Merge branch 'jc/merge-bases'

2012-09-11T18:36:05Z

Optimise the "merge-base" computation a bit, and also update its users that do not need the full merge-base information to call a cheaper subset. * jc/merge-bases: reduce_heads(): reimplement on top of remove_redundant() merge-base: "--is-ancestor A B" get_merge_bases_many(): walk from many tips in parallel in_merge_bases(): use paint_down_to_common() merge_bases_many(): split out the logic to paint history in_merge_bases(): omit unnecessary redundant common ancestor reduction http-push: use in_merge_bases() for fast-forward check receive-pack: use in_merge_bases() for fast-forward check in_merge_bases(): support only one "other" commit

submodule: use argv_array instead of hand-building arrays

2012-09-03T04:13:50Z

fetch_populated_submodules() allocates the full argv array it uses to recurse into the submodules from the number of given options plus the six argv values it is going to add. It then initializes it with those values which won't change during the iteration and copies the given options into it. Inside the loop the two argv values different for each submodule get replaced with those currently valid. However, this technique is brittle and error-prone (as the comment to explain the magic number 6 indicates), so let's replace it with an argv_array. Instead of replacing the argv values, push them to the argv_array just before the run_command() call (including the option separating them) and pop them from the argv_array right after that. Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

in_merge_bases(): support only one "other" commit

2012-08-28T01:36:39Z

In early days of its life, I planned to make it possible to compute "is a commit contained in all of these other commits?" with this function, but it turned out that no caller needed it. Just make it take two commit objects and add a comment to say what these two functions do. Signed-off-by: Junio C Hamano