| Message ID | 20211209184928.71413-1-chooglen@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | implement branch --recurse-submodules | expand |
Glen Choo <chooglen@google.com> writes: > This version is functionally identical to v2. I've only addressed > feedback around code organization, i.e. the the merge conflict with > js/branch-track-inherit and making patch 1 easier to review. Thus, some > discussions on [1] are still unaddressed. I do notice that some of my comments on "add --recurse-submodules option for branch creation" are still unaddressed so I'll hold off review until they are.
Jonathan Tan <jonathantanmy@google.com> writes: > Glen Choo <chooglen@google.com> writes: >> This version is functionally identical to v2. I've only addressed >> feedback around code organization, i.e. the the merge conflict with >> js/branch-track-inherit and making patch 1 easier to review. Thus, some >> discussions on [1] are still unaddressed. > > I do notice that some of my comments on "add --recurse-submodules option > for branch creation" are still unaddressed so I'll hold off review until > they are. Are you referring to your comments on v1 [1]? If so, I believe I had addressed them all in v2 (and v3 is mostly a reorganization of v2). Let me know what you think is unaddressed :) [1] https://lore.kernel.org/git/20211124013153.3619998-1-jonathantanmy@google.com
Glen Choo <chooglen@google.com> writes: > Jonathan Tan <jonathantanmy@google.com> writes: > > > Glen Choo <chooglen@google.com> writes: > >> This version is functionally identical to v2. I've only addressed > >> feedback around code organization, i.e. the the merge conflict with > >> js/branch-track-inherit and making patch 1 easier to review. Thus, some > >> discussions on [1] are still unaddressed. > > > > I do notice that some of my comments on "add --recurse-submodules option > > for branch creation" are still unaddressed so I'll hold off review until > > they are. > > Are you referring to your comments on v1 [1]? If so, I believe I had > addressed them all in v2 (and v3 is mostly a reorganization of v2). > > Let me know what you think is unaddressed :) > > [1] https://lore.kernel.org/git/20211124013153.3619998-1-jonathantanmy@google.com Ah...I just saw that you are creating branches through a remote helper [1] and are still using tree_entry() non-recursively [2] (to be specific, I think we need a test where the submodule is at $ROOT/foo/bar, not just $ROOT/foo), and saw your cover letter that said that some comments were unaddressed, and jumped to a conclusion. Looking back, I think that these are my only unaddressed comments. [1] I said "If you want to use setup_tracking() through submodule--helper, I think that needs an explanation as to why a Git command wouldn't work." in https://lore.kernel.org/git/20211129210140.937875-1-jonathantanmy@google.com/ [2] Discussed in https://lore.kernel.org/git/20211123021223.3472472-1-jonathantanmy@google.com/
Ah, I should make my cover letter more explicit then. I believe some of the comments are addressed in the body of the patches, but that's not the most reviewer-friendly way to do it. I'll address the comments out-of-order because it makes a bit more sense this way. All the patch snippets come from https://lore.kernel.org/git/20211209184928.71413-5-chooglen@google.com Jonathan Tan <jonathantanmy@google.com> writes: > I think we need a test where the submodule is at > $ROOT/foo/bar, not just $ROOT/foo This scenario is tested by changing how the test repo is set up: +test_expect_success 'setup superproject and submodule' ' + git init super && + test_commit foo && + git init sub-sub-upstream && + test_commit -C sub-sub-upstream foo && + git init sub-upstream && + git -C sub-upstream submodule add "$TRASH_DIRECTORY/sub-sub-upstream" sub-sub && + git -C sub-upstream commit -m "add submodule" && + git -C super submodule add "$TRASH_DIRECTORY/sub-upstream" sub && + git -C super commit -m "add submodule" && + git -C super config submodule.propagateBranches true && + git -C super/sub submodule update --init +' so the tests are now all written against a superproject with a 2-level submodule. > I just saw that you [...] are still using tree_entry() non-recursively > [2] > [2] Discussed in https://lore.kernel.org/git/20211123021223.3472472-1-jonathantanmy@google.com/ Yes, but this limitation is overcome by having create_branches_recursively() call itself. I documented this caveat on submodules_of_tree(), which is the function that calls tree_entry(). +/** + * Given a treeish, return all submodules in the tree. This only reads + * one level of the tree, so it will not return nested submodules; + * callers that require nested submodules are expected to handle the + * recursion themselves. + */ +void submodules_of_tree(struct repository *r, + const struct object_id *treeish_name, + struct submodule_entry_list *ret); > [1] I said "If you want to use setup_tracking() through > submodule--helper, I think that needs an explanation as to why a Git > command wouldn't work." in > https://lore.kernel.org/git/20211129210140.937875-1-jonathantanmy@google.com/ Now that create_branches_recursively() calls itself, I moved setup_tracking() into create_branches_recursively() instead of having a submodule helper that only calls create_branch() and setup_tracking(). As a result, I think this comment isn't as relevant as before. That said, it might still be unobvious that create_branch() does not do the right thing without setup_tracking(), i.e. # Why doesn't create_branch() just do the right thing? + create_branch(the_repository, name, start_name, force, 0, reflog, quiet, + BRANCH_TRACK_NEVER, dry_run); + setup_tracking(name, tracking_name, track, quiet, 0); I was hoping that readers who were unclear would find the comment on create_branches_recursively() adequate: + * - tracking_name is the name used of the ref that will be used to set + * up tracking, e.g. origin/main. This is propagated to submodules so + * that tracking information will appear as if the branch branched off + * tracking_name instead of start_name (which is a plain commit id for + * submodules). If omitted, start_name is used for tracking (just like + * create_branch()).
Submodule branching RFC: https://lore.kernel.org/git/kl6lv912uvjv.fsf@chooglen-macbookpro.roam.corp.google.com/ Original Submodule UX RFC/Discussion: https://lore.kernel.org/git/YHofmWcIAidkvJiD@google.com/ Contributor Summit submodules Notes: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2110211148060.56@tvgsbejvaqbjf.bet/ Submodule UX overhaul updates: https://lore.kernel.org/git/?q=Submodule+UX+overhaul+update This series implements branch --recurse-submodules as laid out in the Submodule branching RFC (linked above). If there are concerns about the UX/behavior, I would appreciate feedback on the RFC thread as well :) This series is based off js/branch-track-inherit. This version is functionally identical to v2. I've only addressed feedback around code organization, i.e. the the merge conflict with js/branch-track-inherit and making patch 1 easier to review. Thus, some discussions on [1] are still unaddressed. Patch 5 is an optional cleanup of the questionable exit codes that Junio found [1]. I wasn't able to figure out the intent of the original authors, so it is mostly a best-guess at the right exit code. It doesn't cause any tests to fail, but this wasn't covered by tests to begin with. Changes since v2 * Rebase onto js/branch-track-inherit. This series should continue to be the case going forward. * Patch 1 has a smaller diff because the introduction of validate_branch_start() no longer changes the function order thanks to a forward declaration. This artificial forward declaration is removed in a patch 2 (which can just be squashed into patch 1). * Optional cleanup: fix questionable exit codes in patch 5. Changes since v1: * Move the functionality of "git branch --dry-run" into "git submodule-helper create-branch --dry-run" * Add more fields to the submodules_of_tree() struct to reduce the number of allocations made by the caller [2]. Move this functionality to patch 3 (formerly patch 4) and drop patch 1. * Make submodules_of_tree() ignore inactive submodules [3] * Structure the output of the submodules a bit better by adding prefixes to the child process' output (instead of inconsistently indenting the output). ** I wasn't able to find a good way to interleave stdout/stderr correctly, so a less-than-desirable workaround was to route the child process output to stdout/stderr depending on the exit code. ** Eventually, I would like to structure the output of submodules in a report, as Ævar suggested [4]. But at this stage, I think that it's better to spend time getting user feedback on the submodules branching UX and it'll be easier to standardize the output when we've implemented more of the UX :) [1] https://lore.kernel.org/git/xmqqbl1tcptq.fsf@gitster.g [2] https://lore.kernel.org/git/211123.86r1b7uoil.gmgdl@evledraar.gmail.com [3] https://lore.kernel.org/git/3ad3941c-de18-41bf-2e44-4238ae868d79@gmail.com [4] https://lore.kernel.org/git/211123.86v90juovj.gmgdl@evledraar.gmail.com Glen Choo (5): branch: move --set-upstream-to behavior to setup_tracking() branch: remove forward declaration of validate_branch_start() builtin/branch: clean up action-picking logic in cmd_branch() branch: add --recurse-submodules option for branch creation branch.c: replace questionable exit() codes Documentation/config/advice.txt | 3 + Documentation/config/submodule.txt | 8 + advice.c | 1 + advice.h | 1 + branch.c | 336 +++++++++++++++++++++-------- branch.h | 44 +++- builtin/branch.c | 66 ++++-- builtin/checkout.c | 3 +- builtin/submodule--helper.c | 38 ++++ submodule-config.c | 35 +++ submodule-config.h | 35 +++ submodule.c | 11 +- submodule.h | 3 + t/t3200-branch.sh | 17 ++ t/t3207-branch-submodule.sh | 284 ++++++++++++++++++++++++ 15 files changed, 765 insertions(+), 120 deletions(-) create mode 100755 t/t3207-branch-submodule.sh Range-diff against v2: 1: cc212dcd39 ! 1: 8241c0b51a branch: move --set-upstream-to behavior to setup_tracking() @@ Commit message Signed-off-by: Glen Choo <chooglen@google.com> ## branch.c ## -@@ branch.c: int install_branch_config(int flag, const char *local, const char *origin, const - return -1; +@@ branch.c: static int inherit_tracking(struct tracking *tracking, const char *orig_ref) + return 0; } -/* @@ branch.c: int install_branch_config(int flag, const char *local, const char *ori - */ -static void setup_tracking(const char *new_ref, const char *orig_ref, - enum branch_track track, int quiet) --{ -- struct tracking tracking; -- int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE; -- -- memset(&tracking, 0, sizeof(tracking)); ++static void validate_branch_start(struct repository *r, const char *start_name, ++ enum branch_track track, ++ struct object_id *oid, char **real_ref); ++ ++void setup_tracking(const char *new_ref, const char *orig_ref, ++ enum branch_track track, int quiet, int expand_orig) + { + struct tracking tracking; + struct string_list tracking_srcs = STRING_LIST_INIT_DUP; + int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE; ++ char *full_orig_ref; ++ struct object_id unused_oid; + + memset(&tracking, 0, sizeof(tracking)); - tracking.spec.dst = (char *)orig_ref; -- if (for_each_remote(find_tracked_branch, &tracking)) -- return; -- -- if (!tracking.matches) -- switch (track) { -- case BRANCH_TRACK_ALWAYS: -- case BRANCH_TRACK_EXPLICIT: -- case BRANCH_TRACK_OVERRIDE: -- break; -- default: ++ if (expand_orig) ++ validate_branch_start(the_repository, orig_ref, track, &unused_oid, &full_orig_ref); ++ else ++ full_orig_ref = xstrdup(orig_ref); ++ ++ tracking.spec.dst = full_orig_ref; + tracking.srcs = &tracking_srcs; + if (track != BRANCH_TRACK_INHERIT) + for_each_remote(find_tracked_branch, &tracking); +@@ branch.c: static void setup_tracking(const char *new_ref, const char *orig_ref, + case BRANCH_TRACK_OVERRIDE: + break; + default: - return; -- } -- -- if (tracking.matches > 1) -- die(_("Not tracking: ambiguous information for ref %s"), ++ goto cleanup; + } + + if (tracking.matches > 1) + die(_("Not tracking: ambiguous information for ref %s"), - orig_ref); -- -- if (install_branch_config(config_flags, new_ref, tracking.remote, -- tracking.src ? tracking.src : orig_ref) < 0) -- exit(-1); -- -- free(tracking.src); --} -- ++ full_orig_ref); + + if (tracking.srcs->nr < 1) +- string_list_append(tracking.srcs, orig_ref); ++ string_list_append(tracking.srcs, full_orig_ref); + if (install_branch_config_multiple_remotes(config_flags, new_ref, tracking.remote, + tracking.srcs) < 0) + exit(-1); + ++cleanup: + string_list_clear(tracking.srcs, 0); ++ free(full_orig_ref); + } + int read_branch_desc(struct strbuf *buf, const char *branch_name) - { - char *v = NULL; @@ branch.c: N_("\n" "will track its remote counterpart, you may want to use\n" "\"git push -u\" to set the upstream config as you push."); @@ branch.c: void create_branch(struct repository *r, + oidcpy(oid, &commit->object.oid); +} + -+void setup_tracking(const char *new_ref, const char *orig_ref, -+ enum branch_track track, int quiet, int expand_orig) -+{ -+ struct tracking tracking; -+ int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE; -+ char *full_orig_ref; -+ struct object_id unused_oid; -+ -+ memset(&tracking, 0, sizeof(tracking)); -+ if (expand_orig) -+ validate_branch_start(the_repository, orig_ref, track, &unused_oid, &full_orig_ref); -+ else -+ full_orig_ref = xstrdup(orig_ref); -+ -+ tracking.spec.dst = full_orig_ref; -+ if (for_each_remote(find_tracked_branch, &tracking)) -+ goto cleanup; -+ -+ if (!tracking.matches) -+ switch (track) { -+ case BRANCH_TRACK_ALWAYS: -+ case BRANCH_TRACK_EXPLICIT: -+ case BRANCH_TRACK_OVERRIDE: -+ break; -+ default: -+ goto cleanup; -+ } -+ -+ if (tracking.matches > 1) -+ die(_("Not tracking: ambiguous information for ref %s"), -+ full_orig_ref); -+ -+ if (install_branch_config(config_flags, new_ref, tracking.remote, -+ tracking.src ? tracking.src : full_orig_ref) < 0) -+ exit(-1); -+ -+cleanup: -+ free(tracking.src); -+ free(full_orig_ref); -+} -+ +void create_branch(struct repository *r, const char *name, + const char *start_name, int force, int clobber_head_ok, + int reflog, int quiet, enum branch_track track) -: ---------- > 2: b74bcbaade branch: remove forward declaration of validate_branch_start() 2: 320749cc82 = 3: 235173efc9 builtin/branch: clean up action-picking logic in cmd_branch() 3: c0441c6691 = 4: 3dabb8e2fa branch: add --recurse-submodules option for branch creation -: ---------- > 5: 70fb03f882 branch.c: replace questionable exit() codes