Re: [PATCH v4] branch: add flags and config to inherit tracking

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 18, 2021, 22:29 UTC
Message-ID: <xmqqbl2hw10h.fsf@gitster.g>
In-Reply-To: <7ad7507f183332cb2b5fdf2eb76fbbc9dd7199ef.1637085915.git.steadmon@google.com>

Josh Steadmon <steadmon@google.com> writes:

Show 7 quoted lines

> I've addressed Glen's feedback from V3. However, this brings up a new
> issue that was not obvious before: "branch.<name>.merge" can be
> specified more than once. On the other hand, the existing tracking setup
> code supports only a single merge entry. For now I'm defaulting to use
> the first merge entry listed in the branch struct, but I'm curious what
> people think the best solution would be. This may be another point in
> favor of Ævar's suggestion to reuse the copy-branch-config machinery.

Or we can extend "existing tracking setup code" to support multiple merge sources.

How does the "git pull" machinery react to them, by the way? I think the original intention is to support pulling multiple branches from the (single) remote configured for the branch with a single invocation of "git pull", creating an octopus merge, but does it still work, or nobody uses such a crazy curiosity anymore and it was once broken and left in non-working state ever since? What I am dreaming here is if we can safely ignore all but one of them, taking the usual "last-one-wins" rule, after some transition period.

Show 9 quoted lines

> +int parse_opt_tracking_mode(const struct option *opt, const char *arg, int unset) {
> +	if (unset)
> +		*(enum branch_track *)opt->value = BRANCH_TRACK_NEVER;
> +	else if (!arg || !strcmp(arg, "direct"))
> +		*(enum branch_track *)opt->value = BRANCH_TRACK_EXPLICIT;
> +	else if (!strcmp(arg, "inherit"))
> +		*(enum branch_track *)opt->value = BRANCH_TRACK_INHERIT;
> +	else
> +		return error(_("option `--track' expects \"direct\" or \"inherit\""));

According to recent discussion in another thread,

	error(_("option '--%s` expects '%s' or '%s'"),
		"track", "direct", "inherit");

would be more translater friendly, as these three words are not subject to translation? I am not sure if it is really worth it, though.