git/git-submodule.sh, branch v2.24.0

Merge branch 'km/empty-repo-is-still-a-repo'

2019-05-08T15:37:23Z

Running "git add" on a repository created inside the current repository is an explicit indication that the user wants to add it as a submodule, but when the HEAD of the inner repository is on an unborn branch, it cannot be added as a submodule. Worse, the files in its working tree can be added as if they are a part of the outer repository, which is not what the user wants. These problems are being addressed. * km/empty-repo-is-still-a-repo: add: error appropriately on repository with no commits dir: do not traverse repositories with no commits submodule: refuse to add repository with no commits

Merge branch 'nd/submodule-foreach-quiet'

2019-04-25T07:41:24Z

"git submodule foreach --quiet" did not pass the option down correctly, which has been corrected. * nd/submodule-foreach-quiet: submodule foreach: fix " --quiet" not being respected

Merge branch 'dl/submodule-set-branch'

2019-04-25T07:41:18Z

"git submodule" learns "set-branch" subcommand that allows the submodule.*.branch settings to be modified. * dl/submodule-set-branch: submodule: teach set-branch subcommand submodule--helper: teach config subcommand --unset git-submodule.txt: "--branch " option defaults to 'master'

submodule foreach: fix " --quiet" not being respected

2019-04-15T02:58:42Z

Robin reported that git submodule foreach --quiet git pull --quiet origin is not really quiet anymore [1]. "git pull" behaves as if --quiet is not given. This happens because parseopt in submodule--helper will try to parse both --quiet options as if they are foreach's options, not git-pull's. The parsed options are removed from the command line. So when we do pull later, we execute just this git pull origin When calling submodule helper, adding "--" in front of "git pull" will stop parseopt for parsing options that do not really belong to submodule--helper foreach. PARSE_OPT_KEEP_UNKNOWN is removed as a safety measure. parseopt should never see unknown options or something has gone wrong. There are also a couple usage string update while I'm looking at them. While at it, I also add "--" to other subcommands that pass "$@" to submodule--helper. "$@" in these cases are paths and less likely to be --something-like-this. But the point still stands, git-submodule has parsed and classified what are options, what are paths. submodule--helper should never consider paths passed by git-submodule to be options even if they look like one. The test case is also contributed by Robin. [1] it should be quiet before fc1b9243cd (submodule: port submodule subcommand 'foreach' from shell to C, 2018-05-10) because parseopt can't accidentally eat options then. Reported-by: Robin H. Johnson Tested-by: Robin H. Johnson Signed-off-by: Robin H. Johnson Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

submodule: refuse to add repository with no commits

2019-04-10T03:52:48Z

When the path given to 'git submodule add' is an existing repository that is not in the index, the repository is passed to 'git add'. If this repository doesn't have a commit checked out, we don't get a useful result: there is no subproject OID to track, and any untracked files in the sub-repository are added as blobs in the top-level repository. To avoid getting into this state, abort if the path is a repository that doesn't have a commit checked out. Note that this check must come before the 'git add --dry-run' check because the next commit will make 'git add' fail when given a repository that doesn't have a commit checked out. Signed-off-by: Kyle Meyer Signed-off-by: Junio C Hamano

submodule: teach set-branch subcommand

2019-04-10T03:07:16Z

This teaches git-submodule the set-branch subcommand which allows the branch of a submodule to be set through a porcelain command without having to manually manipulate the .gitmodules file. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

Merge branch 'jt/submodule-fetch-errmsg'

2019-04-09T17:14:26Z

Error message update. * jt/submodule-fetch-errmsg: submodule: explain first attempt failure clearly

submodule: explain first attempt failure clearly

2019-03-14T00:36:48Z

When cloning with --recurse-submodules a superproject with at least one submodule with HEAD pointing to an unborn branch, the clone goes something like this: Cloning into 'test'... Submodule '' () registered for path '' Cloning into ''... fatal: Couldn't find remote ref HEAD Unable to fetch in submodule path '' From * branch -> FETCH_HEAD Submodule path '': checked out '' In other words, first, a fetch is done with no hash arguments (that is, a fetch of HEAD) resulting in a "Couldn't find remote ref HEAD" error; then, a fetch is done given a hash, which succeeds. The fetch given a hash was added in fb43e31f2b ("submodule: try harder to fetch needed sha1 by direct fetching sha1", 2016-02-24), and the "Unable to fetch..." message was downgraded from a fatal error to a notice in e30d833671 ("git-submodule.sh: try harder to fetch a submodule", 2018-05-16). This commit improves the notice to be clearer that we are retrying the fetch, and that the previous messages (in particular, the fatal errors from fetch) do not necessarily indicate that the whole command fails. In other words: - If the HEAD-fetch succeeds and we then have the commit we want, git-submodule prints no explanation. - If the HEAD-fetch succeeds and we do not have the commit we want, but the hash-fetch succeeds, git-submodule prints no explanation. - If the HEAD-fetch succeeds and we do not have the commit we want, but the hash-fetch fails, git-submodule prints a fatal error. - If the HEAD-fetch fails, fetch prints a fatal error, and git-submodule informs the user that it will retry by fetching specific commits by hash. - If the hash-fetch then succeeds, git-submodule prints no explanation (besides the ones already printed). - If the HEAD-fetch then fails, git-submodule prints a fatal error. It could be said that we should just eliminate the HEAD-fetch altogether, but that changes some behavior (in particular, some refs that were opportunistically updated would no longer be), so I have left that alone for now. There is an analogous situation with the fetching code in fetch_finish() and surrounding functions. For now, I have added a NEEDSWORK. Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

submodule: document default behavior

2019-02-15T17:55:27Z

submodule's default behavior wasn't documented in both git-submodule.txt and in the usage text of git-submodule. Document the default behavior similar to how git-remote does it. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

Merge branch 'sh/submodule-summary-abbrev-fix'

2019-02-07T06:05:27Z

The "git submodule summary" subcommand showed shortened commit object names by mechanically truncating them at 7-hexdigit, which has been improved to let "rev-parse --short" scale the length of the abbreviation with the size of the repository. * sh/submodule-summary-abbrev-fix: git-submodule.sh: shorten submodule SHA-1s using rev-parse