Re: [PATCH 1/1] config: support setting up a remote tracking branch upon creation

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

 



Ben Boeckel <mathstuf@xxxxxxxxx> writes:

> The `branch.autoSetupMerge` works well for setting up tracking a local
> branch, but there is no mechanism to automatically set up a remote
> tracking situation.

This description is probably insufficient to explain what's missing,
probably because "set up a remote tracking situation" is a bit
fuzzy.

Without this patch, I can do this already:

    $ git checkout -t -b topic origin/topic

And after the above, we have

    [branch "topic"]
	remote = origin
	merge = refs/heads/topic

Of course, you can instead use a short-hand DWIM, e.g.

    $ git checkout topic ;# assuming origin/topic exists

gives us the same thing.  In either case, topic knows to integrate
with the 'topic' branch from remote 'origin' and push back there.

So instead of saying "there is no mechanism to ...", be a bit more
specific what you can and cannot do in this first paragraph.

Then we can describe the solution we'd propose in the second and
subsequent paragraphs.

Thanks.



> +branch.defaultRemote::
> +	When a new branch is created with 'git branch', 'git switch' or 'git
> +	checkout', this value will be used to initialize the
> +	"branch.<name>.remote" setting.

You mean without "-t"?  I offhand do not think of a reason why this
is a good idea.  How would one create local topic branches that you
plan to merge locally into your own larger topic branch to be shared
with others?  Shouldn't there be an easy way to countermand the
setting by this configuration?

> +branch.defaultPushRemote::
> +	When a new branch is created with 'git branch', 'git switch' or 'git
> +	checkout', this value will be used to initialize the
> +	"branch.<name>.pushRemote" setting.

Ditto.

> +branch.defaultMerge::
> +	When a new branch is created with 'git branch', 'git switch' or 'git
> +	checkout', this value will be used to initialize the
> +	"branch.<name>.merge" setting.

So the expected use case is to fork multiple local branches, to
integrate with the same branch from the remote?  I think we can
already do 

    $ git checkout -t -b xyzzy origin/master
    $ git checkout -t -b frotz origin/master

and you can lose -t with branch.autosetupmerge setting.  As the "git
branch" command needs to get the name of your branch (e.g. 'xyzzy'
or 'frotz') and which remote tracking branch you start from
(e.g. 'origin/master'), even with branch.{defaultRemote,defaultMerge}
configuration, you wouldn't lose that many keystrokes, I suspect.

Or do you plan to make

    $ git branch xyzzy

a short-hand for

    $ git branch -t xyzzy origin/master

when defaultRemote and defaultMerge are set to 'origin' and
'refs/heads/master'?  It would be way too confusing to start the
new branch from origin/master in such a case, as everybody learned
that "git branch xyzzy" that does not say where the branch initially
points at uses HEAD.



[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