Re: [PATCH v6 1/5] branch: move --set-upstream-to behavior to dwim_and_setup_tracking()

[Glen Choo <chooglen@google.com>]

Jonathan Tan <jonathantanmy@google.com> writes:

> Glen Choo <chooglen@google.com> 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.