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

Merge branch 'jc/transport-parseopt-fix'

2023-07-27T22:26:37Z

Command line parser fixes. * jc/transport-parseopt-fix: fetch: reject --no-ipv[46] parse-options: introduce OPT_IPVERSION()

Merge branch 'ah/advise-force-pushing'

2023-07-25T19:05:23Z

Help newbies by suggesting that there are cases where force-pushing is a valid and sensible thing to update a branch at a remote repository, rather than reconciling with merge/rebase. * ah/advise-force-pushing: push: don't imply that integration is always required before pushing remote: don't imply that integration is always required before pushing wt-status: don't show divergence advice when committing

parse-options: introduce OPT_IPVERSION()

2023-07-18T21:35:54Z

The command line option parsing for "git clone", "git fetch", and "git push" have duplicated implementations of parsing "--ipv4" and "--ipv6" options, by having two OPT_SET_INT() for "ipv4" and "ipv6". Introduce a new OPT_IPVERSION() macro and use it in these three commands. Signed-off-by: Junio C Hamano

push: don't imply that integration is always required before pushing

2023-07-13T16:14:58Z

In a narrow but common case, the user is the only author of a branch and doesn't mind overwriting the corresponding branch on the remote. This workflow is especially common on GitHub, GitLab, and Gerrit, which keep a permanent record of every version of a branch that is pushed while a pull request is open for that branch. On those platforms, force-pushing is encouraged and is analogous to emailing a new version of a patchset. When giving advice about divergent branches, tell the user about `git pull`, but don't unconditionally instruct the user to do it. A less prescriptive message will help prevent users from thinking that they are required to create an integrated history instead of simply replacing the previous history. Also, don't put `git pull` in an awkward parenthetical, because `git pull` can always be used to reconcile branches and is the normal way to do so. Due to the difficulty of knowing which command for force-pushing is best suited to the user's situation, no specific advice is given about force-pushing. Instead, the user is directed to the Git documentation to read about possible ways forward that do not involve integration. Signed-off-by: Alex Henrie Signed-off-by: Junio C Hamano

Merge branch 'gc/config-context'

2023-07-06T18:54:48Z

Reduce reliance on a global state in the config reading API. * gc/config-context: config: pass source to config_parser_event_fn_t config: add kvi.path, use it to evaluate includes config.c: remove config_reader from configsets config: pass kvi to die_bad_number() trace2: plumb config kvi config.c: pass ctx with CLI config config: pass ctx with config files config.c: pass ctx in configsets config: add ctx arg to config_fn_t urlmatch.h: use config_fn_t type config: inline git_color_default_config

config: add ctx arg to config_fn_t

2023-06-28T21:06:39Z

Add a new "const struct config_context *ctx" arg to config_fn_t to hold additional information about the config iteration operation. config_context has a "struct key_value_info kvi" member that holds metadata about the config source being read (e.g. what kind of config source it is, the filename, etc). In this series, we're only interested in .kvi, so we could have just used "struct key_value_info" as an arg, but config_context makes it possible to add/adjust members in the future without changing the config_fn_t signature. We could also consider other ways of organizing the args (e.g. moving the config name and value into config_context or key_value_info), but in my experiments, the incremental benefit doesn't justify the added complexity (e.g. a config_fn_t will sometimes invoke another config_fn_t but with a different config value). In subsequent commits, the .kvi member will replace the global "struct config_reader" in config.c, making config iteration a global-free operation. It requires much more work for the machinery to provide meaningful values of .kvi, so for now, merely change the signature and call sites, pass NULL as a placeholder value, and don't rely on the arg in any meaningful way. Most of the changes are performed by contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every config_fn_t: - Modifies the signature to accept "const struct config_context *ctx" - Passes "ctx" to any inner config_fn_t, if needed - Adds UNUSED attributes to "ctx", if needed Most config_fn_t instances are easily identified by seeing if they are called by the various config functions. Most of the remaining ones are manually named in the .cocci patch. Manual cleanups are still needed, but the majority of it is trivial; it's either adjusting config_fn_t that the .cocci patch didn't catch, or adding forward declarations of "struct config_context ctx" to make the signatures make sense. The non-trivial changes are in cases where we are invoking a config_fn_t outside of config machinery, and we now need to decide what value of "ctx" to pass. These cases are: - trace2/tr2_cfg.c:tr2_cfg_set_fl() This is indirectly called by git_config_set() so that the trace2 machinery can notice the new config values and update its settings using the tr2 config parsing function, i.e. tr2_cfg_cb(). - builtin/checkout.c:checkout_main() This calls git_xmerge_config() as a shorthand for parsing a CLI arg. This might be worth refactoring away in the future, since git_xmerge_config() can call git_default_config(), which can do much more than just parsing. Handle them by creating a KVI_INIT macro that initializes "struct key_value_info" to a reasonable default, and use that to construct the "ctx" arg. Signed-off-by: Glen Choo Signed-off-by: Junio C Hamano

cache.h: remove this no-longer-used header

2023-06-21T20:39:53Z

Since this header showed up in some places besides just #include statements, update/clean-up/remove those other places as well. Note that compat/fsmonitor/fsm-path-utils-darwin.c previously got away with violating the rule that all files must start with an include of git-compat-util.h (or a short-list of alternate headers that happen to include it first). This change exposed the violation and caused it to stop building correctly; fix it by having it include git-compat-util.h first, as per policy. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'tl/push-branches-is-an-alias-for-all'

2023-05-15T20:59:05Z

"git push --all" gained an alias "git push --branches". * tl/push-branches-is-an-alias-for-all: t5583: fix shebang line push: introduce '--branches' option

push: introduce '--branches' option

2023-05-06T21:36:43Z

The '--all' option of git-push built-in cmd support to push all branches (refs under refs/heads) to remote. Under the usage, a user can easlily work in some scenarios, for example, branches synchronization and batch upload. The '--all' was introduced for a long time, meanwhile, git supports to customize the storage location under "refs/". when a new git user see the usage like, 'git push origin --all', we might feel like we're pushing _all_ the refs instead of just branches without looking at the documents until we found the related description of it or '--mirror'. To ensure compatibility, we cannot rename '--all' to another name directly, one way is, we can try to add a new option '--heads' which be identical with the functionality of '--all' to let the user understand the meaning of representation more clearly. Actually, We've more or less named options this way already, for example, in 'git-show-ref' and 'git ls-remote'. At the same time, we fix a related issue about the wrong help information of '--all' option in code and add some test cases in t5523, t5543 and t5583. Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

hash-ll.h: split out of hash.h to remove dependency on repository.h

2023-04-24T19:47:32Z

hash.h depends upon and includes repository.h, due to the definition and use of the_hash_algo (defined as the_repository->hash_algo). However, most headers trying to include hash.h are only interested in the layout of the structs like object_id. Move the parts of hash.h that do not depend upon repository.h into a new file hash-ll.h (the "low level" parts of hash.h), and adjust other files to use this new header where the convenience inline functions aren't needed. This allows hash.h and object.h to be fairly small, minimal headers. It also exposes a lot of hidden dependencies on both path.h (which was brought in by repository.h) and repository.h (which was previously implicitly brought in by object.h), so also adjust other files to be more explicit about what they depend upon. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano