2018-10-27 08:22:42 +02:00
|
|
|
branch.autoSetupMerge::
|
2019-03-29 11:39:05 +01:00
|
|
|
Tells 'git branch', 'git switch' and 'git checkout' to set up new branches
|
2018-10-27 08:22:42 +02:00
|
|
|
so that linkgit:git-pull[1] will appropriately merge from the
|
|
|
|
starting point branch. Note that even if this option is not set,
|
|
|
|
this behavior can be chosen per-branch using the `--track`
|
|
|
|
and `--no-track` options. The valid settings are: `false` -- no
|
|
|
|
automatic setup is done; `true` -- automatic setup is done when the
|
|
|
|
starting point is a remote-tracking branch; `always` --
|
|
|
|
automatic setup is done when the starting point is either a
|
branch: add flags and config to inherit tracking
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).
Finally, teach branch.autoSetupMerge a new "inherit" option. When this
is set, "--track=inherit" becomes the default behavior.
[1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21 04:30:23 +01:00
|
|
|
local branch or remote-tracking branch; `inherit` -- if the starting point
|
|
|
|
has a tracking configuration, it is copied to the new
|
branch: new autosetupmerge option 'simple' for matching branches
With the default push.default option, "simple", beginners are
protected from accidentally pushing to the "wrong" branch in
centralized workflows: if the remote tracking branch they would push
to does not have the same name as the local branch, and they try to do
a "default push", they get an error and explanation with options.
There is a particular centralized workflow where this often happens:
a user branches to a new local topic branch from an existing
remote branch, eg with "checkout -b feature1 origin/master". With
the default branch.autosetupmerge configuration (value "true"), git
will automatically add origin/master as the upstream tracking branch.
When the user pushes with a default "git push", with the intention of
pushing their (new) topic branch to the remote, they get an error, and
(amongst other things) a suggestion to run "git push origin HEAD".
If they follow this suggestion the push succeeds, but on subsequent
default pushes they continue to get an error - so eventually they
figure out to add "-u" to change the tracking branch, or they spelunk
the push.default config doc as proposed and set it to "current", or
some GUI tooling does one or the other of these things for them.
When one of their coworkers later works on the same topic branch,
they don't get any of that "weirdness". They just "git checkout
feature1" and everything works exactly as they expect, with the shared
remote branch set up as remote tracking branch, and push and pull
working out of the box.
The "stable state" for this way of working is that local branches have
the same-name remote tracking branch (origin/feature1 in this
example), and multiple people can work on that remote feature branch
at the same time, trusting "git pull" to merge or rebase as required
for them to be able to push their interim changes to that same feature
branch on that same remote.
(merging from the upstream "master" branch, and merging back to it,
are separate more involved processes in this flow).
There is a problem in this flow/way of working, however, which is that
the first user, when they first branched from origin/master, ended up
with the "wrong" remote tracking branch (different from the stable
state). For a while, before they pushed (and maybe longer, if they
don't use -u/--set-upstream), their "git pull" wasn't getting other
users' changes to the feature branch - it was getting any changes from
the remote "master" branch instead (a completely different class of
changes!)
An experienced git user might say "well yeah, that's what it means to
have the remote tracking branch set to origin/master!" - but the
original user above didn't *ask* to have the remote master branch
added as remote tracking branch - that just happened automatically
when they branched their feature branch. They didn't necessarily even
notice or understand the meaning of the "set up to track 'origin/master'"
message when they created the branch - especially if they are using a
GUI.
Looking at how to fix this, you might think "OK, so disable auto setup
of remote tracking - set branch.autosetupmerge to false" - but that
will inconvenience the *second* user in this story - the one who just
wanted to start working on the topic branch. The first and second
users swap roles at different points in time of course - they should
both have a sane configuration that does the right thing in both
situations.
Make this "branches have the same name locally as on the remote"
workflow less painful / more obvious by introducing a new
branch.autosetupmerge option called "simple", to match the same-name
"push.default" option that makes similar assumptions.
This new option automatically sets up tracking in a *subset* of the
current default situations: when the original ref is a remote tracking
branch *and* has the same branch name on the remote (as the new local
branch name).
Update the error displayed when the 'push.default=simple' configuration
rejects a mismatching-upstream-name default push, to offer this new
branch.autosetupmerge option that will prevent this class of error.
With this new configuration, in the example situation above, the first
user does *not* get origin/master set up as the tracking branch for
the new local branch. If they "git pull" in their new local-only
branch, they get an error explaining there is no upstream branch -
which makes sense and is helpful. If they "git push", they get an
error explaining how to push *and* suggesting they specify
--set-upstream - which is exactly the right thing to do for them.
This new option is likely not appropriate for users intentionally
implementing a "triangular workflow" with a shared upstream tracking
branch, that they "git pull" in and a "private" feature branch that
they push/force-push to just for remote safe-keeping until they are
ready to push up to the shared branch explicitly/separately. Such
users are likely to prefer keeping the current default
merge.autosetupmerge=true behavior, and change their push.default to
"current".
Also extend the existing branch tests with three new cases testing
this option - the obvious matching-name and non-matching-name cases,
and also a non-matching-ref-type case. The matching-name case needs to
temporarily create an independent repo to fetch from, as the general
strategy of using the local repo as the remote in these tests
precludes locally branching with the same name as in the "remote".
Signed-off-by: Tao Klerks <tao@klerks.biz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-29 11:56:44 +02:00
|
|
|
branch; `simple` -- automatic setup is done only when the starting point
|
|
|
|
is a remote-tracking branch and the new branch has the same name as the
|
|
|
|
remote branch. This option defaults to true.
|
2018-10-27 08:22:42 +02:00
|
|
|
|
|
|
|
branch.autoSetupRebase::
|
2019-03-29 11:39:05 +01:00
|
|
|
When a new branch is created with 'git branch', 'git switch' or 'git checkout'
|
2018-10-27 08:22:42 +02:00
|
|
|
that tracks another branch, this variable tells Git to set
|
|
|
|
up pull to rebase instead of merge (see "branch.<name>.rebase").
|
|
|
|
When `never`, rebase is never automatically set to true.
|
|
|
|
When `local`, rebase is set to true for tracked branches of
|
|
|
|
other local branches.
|
|
|
|
When `remote`, rebase is set to true for tracked branches of
|
|
|
|
remote-tracking branches.
|
|
|
|
When `always`, rebase will be set to true for all tracking
|
|
|
|
branches.
|
|
|
|
See "branch.autoSetupMerge" for details on how to set up a
|
|
|
|
branch to track another branch.
|
|
|
|
This option defaults to never.
|
|
|
|
|
|
|
|
branch.sort::
|
|
|
|
This variable controls the sort ordering of branches when displayed by
|
|
|
|
linkgit:git-branch[1]. Without the "--sort=<value>" option provided, the
|
|
|
|
value of this variable will be used as the default.
|
|
|
|
See linkgit:git-for-each-ref[1] field names for valid values.
|
|
|
|
|
|
|
|
branch.<name>.remote::
|
|
|
|
When on branch <name>, it tells 'git fetch' and 'git push'
|
|
|
|
which remote to fetch from/push to. The remote to push to
|
|
|
|
may be overridden with `remote.pushDefault` (for all branches).
|
|
|
|
The remote to push to, for the current branch, may be further
|
|
|
|
overridden by `branch.<name>.pushRemote`. If no remote is
|
push: default to single remote even when not named origin
With "push.default=current" configured, a simple "git push" will push to
the same-name branch on the current branch's branch.<name>.pushRemote, or
remote.pushDefault, or origin. If none of these are defined, the push will
fail with error "fatal: No configured push destination".
The same "default to origin if no config" behavior applies with
"push.default=matching".
Other commands use "origin" as a default when there are multiple options,
but default to the single remote when there is only one - for example,
"git checkout <something>". This "assume the single remote if there is
only one" behavior is more friendly/useful than a defaulting behavior
that only uses the name "origin" no matter what.
Update "git push" to also default to the single remote (and finally fall
back to "origin" as default if there are several), for
"push.default=current" and for other current and future remote-defaulting
push behaviors.
This change also modifies the behavior of ls-remote in a consistent way,
so defaulting not only supplies 'origin', but any single configured remote
also.
Document the change in behavior, correct incorrect assumptions in related
tests, and add test cases reflecting this new single-remote-defaulting
behavior.
Signed-off-by: Tao Klerks <tao@klerks.biz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-29 11:56:45 +02:00
|
|
|
configured, or if you are not on any branch and there is more than
|
|
|
|
one remote defined in the repository, it defaults to `origin` for
|
|
|
|
fetching and `remote.pushDefault` for pushing.
|
2018-10-27 08:22:42 +02:00
|
|
|
Additionally, `.` (a period) is the current local repository
|
|
|
|
(a dot-repository), see `branch.<name>.merge`'s final note below.
|
|
|
|
|
|
|
|
branch.<name>.pushRemote::
|
|
|
|
When on branch <name>, it overrides `branch.<name>.remote` for
|
|
|
|
pushing. It also overrides `remote.pushDefault` for pushing
|
|
|
|
from branch <name>. When you pull from one place (e.g. your
|
|
|
|
upstream) and push to another place (e.g. your own publishing
|
|
|
|
repository), you would want to set `remote.pushDefault` to
|
|
|
|
specify the remote to push to for all branches, and use this
|
|
|
|
option to override it for a specific branch.
|
|
|
|
|
|
|
|
branch.<name>.merge::
|
|
|
|
Defines, together with branch.<name>.remote, the upstream branch
|
|
|
|
for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
|
|
|
|
branch to merge and can also affect 'git push' (see push.default).
|
|
|
|
When in branch <name>, it tells 'git fetch' the default
|
|
|
|
refspec to be marked for merging in FETCH_HEAD. The value is
|
|
|
|
handled like the remote part of a refspec, and must match a
|
|
|
|
ref which is fetched from the remote given by
|
|
|
|
"branch.<name>.remote".
|
|
|
|
The merge information is used by 'git pull' (which at first calls
|
|
|
|
'git fetch') to lookup the default branch for merging. Without
|
|
|
|
this option, 'git pull' defaults to merge the first refspec fetched.
|
|
|
|
Specify multiple values to get an octopus merge.
|
|
|
|
If you wish to setup 'git pull' so that it merges into <name> from
|
|
|
|
another branch in the local repository, you can point
|
|
|
|
branch.<name>.merge to the desired branch, and use the relative path
|
|
|
|
setting `.` (a period) for branch.<name>.remote.
|
|
|
|
|
|
|
|
branch.<name>.mergeOptions::
|
|
|
|
Sets default options for merging into branch <name>. The syntax and
|
|
|
|
supported options are the same as those of linkgit:git-merge[1], but
|
|
|
|
option values containing whitespace characters are currently not
|
|
|
|
supported.
|
|
|
|
|
|
|
|
branch.<name>.rebase::
|
|
|
|
When true, rebase the branch <name> on top of the fetched branch,
|
|
|
|
instead of merging the default branch from the default remote when
|
|
|
|
"git pull" is run. See "pull.rebase" for doing this in a non
|
|
|
|
branch-specific manner.
|
|
|
|
+
|
2020-01-27 08:04:27 +01:00
|
|
|
When `merges` (or just 'm'), pass the `--rebase-merges` option to 'git rebase'
|
2018-10-27 08:22:42 +02:00
|
|
|
so that the local merge commits are included in the rebase (see
|
|
|
|
linkgit:git-rebase[1] for details).
|
|
|
|
+
|
2020-01-27 08:04:27 +01:00
|
|
|
When the value is `interactive` (or just 'i'), the rebase is run in interactive
|
|
|
|
mode.
|
2018-10-27 08:22:42 +02:00
|
|
|
+
|
|
|
|
*NOTE*: this is a possibly dangerous operation; do *not* use
|
|
|
|
it unless you understand the implications (see linkgit:git-rebase[1]
|
|
|
|
for details).
|
|
|
|
|
|
|
|
branch.<name>.description::
|
|
|
|
Branch description, can be edited with
|
|
|
|
`git branch --edit-description`. Branch description is
|
|
|
|
automatically added in the format-patch cover letter or
|
|
|
|
request-pull summary.
|