git/builtin/push.c, branch v2.37.2

push: fix capitalisation of the option name autoSetupMerge

2022-06-15T18:45:46Z

This was found during l10n process by Jiang Xin. Reported-by: Jiang Xin Signed-off-by: Fangyi Zhou Signed-off-by: Junio C Hamano

push: new config option "push.autoSetupRemote" supports "simple" push

2022-04-29T18:20:55Z

In some "simple" centralized workflows, users expect remote tracking branch names to match local branch names. "git push" pushes to the remote version/instance of the branch, and "git pull" pulls any changes to the remote branch (changes made by the same user in another place, or by other users). This expectation is supported by the push.default default option "simple" which refuses a default push for a mismatching tracking branch name, and by the new branch.autosetupmerge option, "simple", which only sets up remote tracking for same-name remote branches. When a new branch has been created by the user and has not yet been pushed (and push.default is not set to "current"), the user is prompted with a "The current branch %s has no upstream branch" error, and instructions on how to push and add tracking. This error is helpful in that following the advice once per branch "resolves" the issue for that branch forever, but inconvenient in that for the "simple" centralized workflow, this is always the right thing to do, so it would be better to just do it. Support this workflow with a new config setting, push.autoSetupRemote, which will cause a default push, when there is no remote tracking branch configured, to push to the same-name on the remote and --set-upstream. Also add a hint offering this new option when the "The current branch %s has no upstream branch" error is encountered, and add corresponding tests. Signed-off-by: Tao Klerks Signed-off-by: Junio C Hamano

branch: new autosetupmerge option 'simple' for matching branches

2022-04-29T18:20:55Z

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 Signed-off-by: Junio C Hamano

i18n: factorize "invalid value" messages

2022-02-04T21:58:28Z

Use the same message when an invalid value is passed to a command line option or a configuration variable. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

i18n: turn "options are incompatible" into "cannot be used together"

2022-01-05T21:29:23Z

Signed-off-by: Jean-Noël Avila Reviewed-by: Johannes Sixt Signed-off-by: Junio C Hamano

advice: remove read uses of most global `advice_` variables

2021-08-25T19:07:52Z

In c4a09cc9ccb (Merge branch 'hw/advise-ng', 2020-03-25), a new API for accessing advice variables was introduced and deprecated `advice_config` in favor of a new array, `advice_setting`. This patch ports all but two uses which read the status of the global `advice_` variables over to the new `advice_enabled` API. We'll deal with advice_add_embedded_repo and advice_graft_file_deprecated separately. Signed-off-by: Ben Boeckel Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

push: don't get a full remote object

2021-06-02T01:12:03Z

All we need to know is that their names are the same. Additionally this might be easier to parse for some since remote_for_branch is more descriptive than remote_get(NULL). Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

push: only check same_remote when needed

2021-06-02T01:12:02Z

Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

push: remove trivial function

2021-06-02T01:12:02Z

It's a single line that is used in a single place, and the variable has the same name as the function. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

push: remove redundant check

2021-06-02T01:12:02Z

If fetch_remote is NULL (i.e. the branch remote is invalid), then it can't possibly be same as remote, which can't be NULL. The check is redundant, and so is the extra variable. Also, fix the Yoda condition: we want to check if remote is the same as the branch remote, not the other way around. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano