Re: [PATCH v6 2/3] branch: add flags and config to inherit tracking

[Josh Steadmon <steadmon@google.com>]

On 2021.12.16 13:27, Glen Choo wrote:
> Josh Steadmon <steadmon@google.com> writes:
> 
> > @@ -192,11 +220,15 @@ static void setup_tracking(const char *new_ref, const char *orig_ref,
> >  			   enum branch_track track, int quiet)
> >  {
> >  	struct tracking tracking;
> > +	struct string_list tracking_srcs = STRING_LIST_INIT_DUP;
> >  	int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE;
> >  
> >  	memset(&tracking, 0, sizeof(tracking));
> >  	tracking.spec.dst = (char *)orig_ref;
> > -	if (for_each_remote(find_tracked_branch, &tracking))
> > +	tracking.srcs = &tracking_srcs;
> > +	if (track != BRANCH_TRACK_INHERIT)
> > +		for_each_remote(find_tracked_branch, &tracking);
> > +	else if (inherit_tracking(&tracking, orig_ref))
> >  		return;
> >  
> >  	if (!tracking.matches)
> > @@ -204,6 +236,7 @@ static void setup_tracking(const char *new_ref, const char *orig_ref,
> >  		case BRANCH_TRACK_ALWAYS:
> >  		case BRANCH_TRACK_EXPLICIT:
> >  		case BRANCH_TRACK_OVERRIDE:
> > +		case BRANCH_TRACK_INHERIT:
> >  			break;
> >  		default:
> >  			return;
> > @@ -213,11 +246,13 @@ static void setup_tracking(const char *new_ref, const char *orig_ref,
> >  		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)
> > +	if (tracking.srcs->nr < 1 && track != BRANCH_TRACK_INHERIT)
> > +		string_list_append(tracking.srcs, orig_ref);
> 
> So, in the BRANCH_TRACK_{ALWAYS,EXPLICIT,OVERRIDE} cases, we append
> orig_ref because we expect orig_ref to be a local ref that the caller
> wants to track. This is not the case with BRANCH_TRACK_INHERIT, where we
> want to inherit the configuration and we no longer care about orig_ref.
> 
> This is correct, though it's more unobvious than what I originally
> envisioned when I commented on [1]. As a small nit, it might benefit
> from a clarifying comment, but this is fine as it is :)

Actually, you're right, the `track != BRANCH_TRACK_INHERIT` condition is
superfluous. The only way we could have BRANCH_TRACK_INHERIT and
tracking.srcs->nr < 1 at the same time would be if there were no
"branch.*.merge" entries in the config to inherit, but if that were true
then we would have had returned from this function earlier.

> > diff --git a/t/t2027-checkout-track.sh b/t/t2027-checkout-track.sh
> > index 4453741b96..49c7def21c 100755
> > --- a/t/t2027-checkout-track.sh
> > +++ b/t/t2027-checkout-track.sh
> > @@ -24,4 +24,27 @@ test_expect_success 'checkout --track -b rejects an extra path argument' '
> >  	test_i18ngrep "cannot be used with updating paths" err
> >  '
> >  
> > +test_expect_success 'checkout --track -b overrides autoSetupMerge=inherit' '
> > +	# Set up tracking config on main
> > +	test_config branch.main.remote origin &&
> > +	test_config branch.main.merge refs/heads/main &&
> > +	test_config branch.autoSetupMerge inherit &&
> > +	# With --track=inherit, we copy the tracking config from main
> > +	git checkout --track=inherit -b b1 main &&
> > +	test_cmp_config origin branch.b1.remote &&
> > +	test_cmp_config refs/heads/main branch.b1.merge &&
> > +	# With branch.autoSetupMerge=inherit, we do the same
> > +	git checkout -b b2 main &&
> > +	test_cmp_config origin branch.b2.remote &&
> > +	test_cmp_config refs/heads/main branch.b2.merge &&
> > +	# But --track overrides this
> > +	git checkout --track -b b3 main &&
> > +	test_cmp_config . branch.b3.remote &&
> > +	test_cmp_config refs/heads/main branch.b3.merge &&
> > +	# And --track=direct does as well
> > +	git checkout --track=direct -b b4 main &&
> > +	test_cmp_config . branch.b4.remote &&
> > +	test_cmp_config refs/heads/main branch.b4.merge
> 
> Nit: in both cases, the expected result is that branch.b*.merge is
> "refs/heads/main". so the difference between --track=direct and
> --track=inherit would be more obvious if main tracked something other
> than origin/main.

Fixed in V7.


> As an side, the comments in the tests make it really readable :)
> 
> Overall this patch looks good.
> 
> [1] https://lore.kernel.org/git/kl6lfsr3c3j7.fsf@chooglen-macbookpro.roam.corp.google.com