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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021.12.07 10:08, Ævar Arnfjörð Bjarmason wrote:
> 
> On Mon, Dec 06 2021, Josh Steadmon wrote:
> 
> > It can be helpful when creating a new branch to use the existing
> > tracking configuration from the branch point. However, there is
> > currently not a method to automatically do so.
> >
> > Teach git-{branch,checkout,switch} an "inherit" argument to the
> > "--track" option. When this is set, creating a new branch will cause the
> > tracking configuration to default to the configuration of the branch
> > point, if set.
> >
> > For example, if branch "main" tracks "origin/main", and we run
> > `git checkout --track=inherit -b feature main`, then branch "feature"
> > will track "origin/main". Thus, `git status` will show us how far
> > ahead/behind we are from origin, and `git pull` will pull from origin.
> >
> > This is particularly useful when creating branches across many
> > submodules, such as with `git submodule foreach ...` (or if running with
> > a patch such as [1], which we use at $job), as it avoids having to
> > manually set tracking info for each submodule.
> >
> > Since we've added an argument to "--track", also add "--track=direct" as
> > another way to explicitly get the original "--track" behavior ("--track"
> > without an argument still works as well).
> > @@ -10,7 +10,8 @@ enum branch_track {
> >  	BRANCH_TRACK_REMOTE,
> >  	BRANCH_TRACK_ALWAYS,
> >  	BRANCH_TRACK_EXPLICIT,
> > -	BRANCH_TRACK_OVERRIDE
> > +	BRANCH_TRACK_OVERRIDE,
> > +	BRANCH_TRACK_INHERIT
> >  };
> 
> So we've got 5 items in this enum...
> 
> >  
> >  extern enum branch_track git_branch_track;
> > diff --git a/builtin/branch.c b/builtin/branch.c
> > index b23b1d1752..ebde5023c3 100644
> > --- a/builtin/branch.c
> > +++ b/builtin/branch.c
> > @@ -632,8 +632,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> >  		OPT__VERBOSE(&filter.verbose,
> >  			N_("show hash and subject, give twice for upstream branch")),
> >  		OPT__QUIET(&quiet, N_("suppress informational messages")),
> > -		OPT_SET_INT('t', "track",  &track, N_("set up tracking mode (see git-pull(1))"),
> > -			BRANCH_TRACK_EXPLICIT),
> > +		OPT_CALLBACK_F('t', "track",  &track, "direct|inherit",
> > +			N_("set branch tracking configuration"),
> > +			PARSE_OPT_OPTARG | PARSE_OPT_LITERAL_ARGHELP,
> > +			parse_opt_tracking_mode),
> >  		OPT_SET_INT_F(0, "set-upstream", &track, N_("do not use"),
> >  			BRANCH_TRACK_OVERRIDE, PARSE_OPT_HIDDEN),
> 
> But map --track, --track=direct --track=inherit to 3/5 of them. Will it
> ever make sense to do the oher 2/5 (I really haven't checked)....
> 
> >  		OPT_STRING('u', "set-upstream-to", &new_upstream, N_("upstream"), N_("change the upstream info")),
> > diff --git a/builtin/checkout.c b/builtin/checkout.c
> > index b5d477919a..45dab414ea 100644
> > --- a/builtin/checkout.c
> > +++ b/builtin/checkout.c
> > @@ -1532,8 +1532,10 @@ static struct option *add_common_switch_branch_options(
> >  {
> >  	struct option options[] = {
> >  		OPT_BOOL('d', "detach", &opts->force_detach, N_("detach HEAD at named commit")),
> > -		OPT_SET_INT('t', "track",  &opts->track, N_("set upstream info for new branch"),
> > -			BRANCH_TRACK_EXPLICIT),
> > +		OPT_CALLBACK_F('t', "track",  &opts->track, "direct|inherit",
> > +			N_("set up tracking mode (see git-pull(1))"),
> > +			PARSE_OPT_OPTARG | PARSE_OPT_LITERAL_ARGHELP,
> > +			parse_opt_tracking_mode),
> >  		OPT__FORCE(&opts->force, N_("force checkout (throw away local modifications)"),
> >  			   PARSE_OPT_NOCOMPLETE),
> >  		OPT_STRING(0, "orphan", &opts->new_orphan_branch, N_("new-branch"), N_("new unparented branch")),
> 
> I wonder if this interface wouldn't be a lot simpler as:
> 
>     --track
>     --track-explicit --track-direct --track-inherit
> 
> Both because it'll work better for auto-complete, and we can (and
> presumably some will want) just make --track mean whatever configured
> --track-THING you want.

If I understand you correctly, I disagree here. I think you're saying
that if you always (or usually) want a specific tracking mode, you have
to both set the config appropriately and remember to pass `--track` on
the command line? Seems simpler to just let the config take precedence
in the absence of a flag. But I think I may have misunderstood you.

> in any case, isn't there a NONEG missing here, or is --no-track-direct
> etc. handled by OPT_CALLBACK_F() (I forget...).

Yeah, --no-track is correctly handled. It sets BRANCH_TRACK_NEVER, so
that you can override a branch.autosetupmerge=always config if
necessary.


> >  	if (!strcmp(var, "branch.autosetupmerge")) {
> > -		if (value && !strcasecmp(value, "always")) {
> > +		if (value && !strcmp(value, "always")) {
> 
> ...This probably makes sense, but it seems like the behavior change of
> "let's not take this case-insensitive" should be split up into its own
> change...

Done in V6.


> > +	test_must_fail git rev-parse --verify HEAD^ &&
> > +	git checkout main &&
> > +	git config branch.autosetupmerge inherit &&
> > +	git checkout --orphan eta &&
> > +	test -z "$(git config branch.eta.merge)" &&
> > +	test -z "$(git config branch.eta.remote)" &&
> 
> Better with the test_must_be_empty etc. helpers.
> 
> > +	test refs/heads/eta = "$(git symbolic-ref HEAD)" &&
> 
> and this with test_cmp.
> 
> (ditto occurances below)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux