]> git.ipfire.org Git - thirdparty/git.git/commit
submodule--helper update: use display path helper
authorGlen Choo <chooglen@google.com>
Fri, 1 Jul 2022 02:11:52 +0000 (19:11 -0700)
committerJunio C Hamano <gitster@pobox.com>
Fri, 1 Jul 2022 05:41:45 +0000 (22:41 -0700)
commit618b8445d92c60d9e1e4609e7c56a941bb3862b9
tree5aecf36814abe8d7cd53383126c06a48fa126316
parent8fc36c39d9f68f5c556f9d8a2713116824a83dd7
submodule--helper update: use display path helper

There are two locations in prepare_to_clone_next_submodule() that
manually calculate the submodule display path, but should just use
do_get_submodule_displaypath() for consistency.

Do this replacement and reorder the code slightly to avoid computing
the display path twice.

Until the preceding commit this code had never been tested, with our
newly added tests we can see that both these sites have been computing
the display path incorrectly ever since they were introduced in
48308681b0 (git submodule update: have a dedicated helper for cloning,
2016-02-29) [1]:

- The first hunk puts a "/" between recursive_prefix and ce->name, but
  recursive_prefix already ends with "/".
- The second hunk calls relative_path() on recursive_prefix and
  ce->name, but relative_path() only makes sense when both paths share
  the same base directory. This is never the case here:
  - recursive_prefix is the path from the topmost superproject to the
    current submodule
  - ce->name is the path from the root of the current submodule to its
    submodule.
  so, e.g. recursive_prefix="super" and ce->name="submodule" produces
  displayname="../super" instead of "super/submodule".

[1] I verified this by applying the tests to 48308681b0.

Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/submodule--helper.c
t/t7406-submodule-update.sh