Josh Steadmon <steadmon@xxxxxxxxxx> writes:
> 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.
> +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.
