Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:
> Glen Choo <chooglen@xxxxxxxxxx> writes:
>> This appears to be a leftover from 4fc5006676 (Add
>> branch --set-upstream, 2010-01-18), when --set-upstream would sometimes
>> create a branch and sometimes update tracking information without
>> creating a branch. However, we no longer support --set-upstream, so it
>> makes more sense to set tracking information with another function and
>> use create_branch() only to create branches. In a later commit, we will
>> remove the now-unnecessary logic from create_branch() so that "dry_run"
>> becomes trivial to implement.
>
> What do you mean by "leftover"?
>
> Aside from that, the pertinent information is that the mentioned commit
> changed create_branch() to no longer always create a branch, instead
> sometimes creating a branch and sometimes updating tracking information
> (and sometimes both). I don't think whether we support "--set-upstream"
> is material here.
I was hoping to explain why we made the decision to reuse
create_branch() to set tracking information (it made sense with
--set-upstream) and why it now makes sense to use another function
(because we no longer have --set-upstream).
But maybe this justification is unnecessary, and the desire to add a
dry_run parameter is enough.
>
> Also, what is the now-unnecessary logic to be removed in a later commit?
This would be the logic that makes create_branch() not create branches,
which is addressed in your proposed commit message.
>> Introduce dwim_and_setup_tracking(), which replaces create_branch()
>> in `git branch --set-upstream-to`. Ensure correctness by moving the DWIM
>> and branch validation logic from create_branch() into a helper function,
>> dwim_branch_start(), so that the logic is shared by both functions.
>
> I think it's clearer to just say what we're refactoring instead of
> saying that we're introducing a function and making sure that it is
> correct, not by testing (as one would expect), but by moving logic.
>
> I would write the commit message like this:
>
> This commit is in preparation for a future commit that adds a dry_run
> parameter to create_branch() (that is needed for supporting "git
> branch --recurse-submodules", to be introduced in another future
> commit).
>
> create_branch() used to always create a branch, but this was changed
> in 4fc5006676 (Add branch --set-upstream, 2010-01-18), when it was
> changed to be also able to set tracking information.
>
> Refactor the code that sets tracking information into its own
> functions dwim_branch_start() and dwim_and_setup_tracking(). Also
> change an invocation of create_branch() in cmd_branch() in
> builtin/branch.c to use dwim_and_setup_tracking(), since that
> invocation is only for setting tracking information.
>
> And if this is true:
>
> As of this commit, create_branch() still sometimes does not create
> branches, but this will be fixed in a subsequent commit.
Hm, I see. This makes sense, I'll incorporate some of your suggestions :)
>> @@ -244,7 +246,7 @@ static void setup_tracking(const char *new_ref, const char *orig_ref,
>> case BRANCH_TRACK_INHERIT:
>> break;
>> default:
>> - return;
>> + goto cleanup;
>> }
>>
>> if (tracking.matches > 1)
>> @@ -257,6 +259,7 @@ static void setup_tracking(const char *new_ref, const char *orig_ref,
>> tracking.remote, tracking.srcs) < 0)
>> exit(-1);
>>
>> +cleanup:
>> string_list_clear(tracking.srcs, 0);
>> }
>>
>
> This seems like it's just for avoiding a memory leak, and is unrelated
> to this commit, so it should go into its own commit.
Thanks for the catch.
>
>> @@ -340,31 +343,37 @@ N_("\n"
>> "will track its remote counterpart, you may want to use\n"
>> "\"git push -u\" to set the upstream config as you push.");
>>
>> -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)
>
> This seems to have the same parameters as the "+" version, but wrapped
> differently - don't rewrap unless you're also changing it.
Ah, I didn't realize it had rewrapped. Thanks for the catch.
>> +/**
>> + * DWIMs a user-provided ref to determine the starting point for a
>> + * branch and validates it, where:
>> + *
>> + * - r is the repository to validate the branch for
>> + *
>> + * - start_name is the ref that we would like to test. This is
>> + * expanded with DWIM and assigned to out_real_ref.
>> + *
>> + * - track is the tracking mode of the new branch. If tracking is
>> + * explicitly requested, start_name must be a branch (because
>> + * otherwise start_name cannot be tracked)
>> + *
>> + * - out_oid is an out parameter containing the object_id of start_name
>> + *
>> + * - out_real_ref is an out parameter containing the full, 'real' form
>> + * of start_name e.g. refs/heads/main instead of main
>> + *
>> + */
>> +static void dwim_branch_start(struct repository *r, const char *start_name,
>> + enum branch_track track, char **out_real_ref,
>> + struct object_id *out_oid)
>
> [snip]
>
>> @@ -401,7 +410,34 @@ void create_branch(struct repository *r,
>>
>> if ((commit = lookup_commit_reference(r, &oid)) == NULL)
>> die(_("Not a valid branch point: '%s'."), start_name);
>> - oidcpy(&oid, &commit->object.oid);
>> + if (out_real_ref)
>> + *out_real_ref = real_ref ? xstrdup(real_ref) : NULL;
>
> I think you can just write "*out_real_ref = real_ref; real_ref = NULL;"
> here, and then not need to xstrdup.
Hm, you are right. The xstrdup was added because the original function
calls FREE_AND_NULL(real_ref) and then checks if real_ref is NULL. But
after the refactor, real_ref is not referenced after the
FREE_AND_NULL(real_ref), so that call can be removed.
I intend to remove the xstrdup, though it will introduce a bit of noise
because that block will no longer be moved wholesale.
