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

Merge branch 'ar/submodule-add'

2021-08-04T20:28:52Z

Rewrite of "git submodule" in C continues. * ar/submodule-add: submodule: drop unused sm_name parameter from show_fetch_remotes() submodule--helper: introduce add-clone subcommand submodule--helper: refactor module_clone() submodule: prefix die messages with 'fatal' t7400: test failure to add submodule in tracked path

submodule--helper: introduce add-clone subcommand

2021-07-12T19:06:21Z

Let's add a new "add-clone" subcommand to `git submodule--helper` with the goal of converting part of the shell code in git-submodule.sh related to `git submodule add` into C code. This new subcommand clones the repository that is to be added, and checks out to the appropriate branch. This is meant to be a faithful conversion that leaves the behaviour of 'cmd_add()' script unchanged. Signed-off-by: Atharva Raykar Mentored-by: Christian Couder Mentored-by: Shourya Shukla Based-on-patch-by: Shourya Shukla Based-on-patch-by: Prathamesh Chavan Helped-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

submodule: prefix die messages with 'fatal'

2021-07-12T19:06:21Z

The standard `die()` function that is used in C code prefixes all the messages passed to it with 'fatal: '. This does not happen with the `die` used in 'git-submodule.sh'. Let's prefix each of the shell die messages with 'fatal: ' so that when they are converted to C code, the error messages stay the same as before the conversion. Note that the shell version of `die` exits with error code 1, while the C version exits with error code 128. In practice, this does not change any behaviour, as no functionality in 'submodule add' and 'submodule update' relies on the value of the exit code. Signed-off-by: Atharva Raykar Mentored-by: Christian Couder Mentored-by: Shourya Shukla Signed-off-by: Junio C Hamano

submodule: remove unnecessary `prefix` based option logic

2021-06-29T03:28:19Z

Over time when parts of submodule have been ported from shell to builtin, many instances of the submodule helper have been added. Also added with them are some unnecessary option passing logic that are based on the `prefix` shell variable which never gets set in their code flows. On analysis, the only shell functions which have a valid usage for the `prefix` shell variable are: - cmd_update: which is the only function which sets the variable and thus uses it properly - cmd_init: which uses the variable via a call from cmd_update So, remove the unnecessary option parsing logic based on the `prefix` shell variable. Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano

submodule update: silence underlying fetch with "--quiet"

2021-05-03T03:24:38Z

Commands such as $ git submodule update --quiet --init --depth=1 involving shallow clones, call the shell function fetch_in_submodule, which in turn invokes git fetch. Pass the --quiet option onward there. Signed-off-by: Nicholas Clark Signed-off-by: Junio C Hamano

submodule: fix fetch_in_submodule logic

2020-11-24T21:14:09Z

Commit 1c1518071c (submodule: use "fetch" logic instead of custom remote discovery, 2020-11-14) rewrote the logic in fetch_in_submodule to do: elif test "$2" -ne "" But this is nonsense in shell: -ne is for numeric comparisons. This should be "=" or more idiomatically: elif test -n "$2" But once we fix that, many tests start failing. Because that commit introduced another problem. The caller that passes 3 arguments looks like this: fetch_in_submodule "$sm_path" $depth "$sha1" Note the unquoted $depth parameter. When it isn't set, the function will see only 2 arguments, and the function has no idea if what it sees in $2 is an option to go on the command line, or a refspec to pass on stdin. In the old code before that commit: fetch_in_submodule () ( sanitize_submodule_env && cd "$1" && - case "$2" in - '') - git fetch ;; - *) - shift - git fetch $(get_default_remote) "$@" ;; - esac we treated those the same, so it didn't matter. But in the new logic (with my fix above): + if test $# -eq 3 + then + echo "$3" | git fetch --stdin "$2" + elif test -n "$n" + then + git fetch "$2" + else + git fetch + fi we use the number of parameters to distinguish the two. Let's insist that the caller pass an empty string for positional parameter two if they want to have a third parameter after it. But that still leaves one problem. In the --stdin block, we unconditionally pass "$2" to git-fetch, even if it's the empty string. Rather than add another conditional, we can use :+ parameter expansion to include it only if it's non-empty. In fact, we can do the same for the elif, too, simplifying it further. Technically this is overkill, since we know the --depth parameter will not have whitespace (and indeed, most callers do not bother quoting it), but it doesn't hurt for the function to be careful. It's somewhat amazing that no tests were failing. I think what happened is that: - the 3-arg form rarely triggered; any call with a non-empty $depth and a $sha1 would work, but one with an empty $depth would only have 2 arguments - because of the wrong arguments to "test", the shell would complain and exit non-zero. So we never ran the middle conditional at all - that left every call running "git fetch" with no arguments. A well-written test could have detected the distinction here, but in practice omitting --depth just means fetching more commits, and fetching everything (rather than a single sha1) works as long as the commit in question is reachable Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

parse-remote: remove this now-unused library

2020-11-16T21:19:30Z

The previous two commits removed the last use of a function in this library, but most of it had been dead code for a while[1][2]. Only the "get_default_remote" function was still being used. Even though we had a manual page for this library it was never intended (or I expect, actually) used outside of git.git. Let's just remove it, if anyone still cares about a function here they can pull them into their own project[3]. 1. Last use of error_on_missing_default_upstream(): d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18) 2. Last use of get_remote_merge_branch(): 49eb8d39c7 ("Remove contrib/examples/*", 2018-03-25) 3. https://lore.kernel.org/git/87a6vmhdka.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

submodule: remove sh function in favor of helper

2020-11-16T21:15:00Z

Remove the now-redundant "get_default_remote" function by converting its last user to the "print-default-remote" helper. As can be seen in 13424764db ("submodule: port submodule subcommand 'sync' from shell to C", 2018-01-15) this helper is already used internally by the C code for submodule remote name discovery. The "get_default_remote" function in "git-parse-remote.sh" will be removed in a follow-up change. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

submodule: use "fetch" logic instead of custom remote discovery

2020-11-16T20:54:43Z

Replace a use of the get_default_remote() function with an invocation of "git fetch" The "fetch" command already has logic to discover the remote for the current branch. However, before it learned to accept a custom refspec *and* use its idea of the default remote, it wasn't possible to get rid of some equivalent of the "get_default_remote" invocation here. As it turns out the recently added "--stdin" option to fetch[1] gives us a way to do that. Let's use it instead. While I'm at it simplify the "fetch_in_submodule" function. It wasn't necessary to pass "$@" to "fetch" since we'd only ever provide one SHA-1 as an argument in the previous "*" codepath (in addition to "--depth=N"). Rewrite the function to more narrowly reflect its use-case. 1. https://lore.kernel.org/git/87eekwf87n.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'td/submodule-update-quiet'

2020-10-05T21:01:53Z

"git submodule update --quiet" did not squelch underlying "rebase" and "pull" commands. * td/submodule-update-quiet: submodule update: silence underlying merge/rebase with "--quiet"