git/Documentation/git-remote.txt, branch v2.45.2

git-remote.txt: fix typo

2024-02-21T18:02:55Z

Signed-off-by: Jakub Wilk Signed-off-by: Junio C Hamano

builtin/remote.c: teach `-v` to list filters for promisor remotes

2022-05-09T17:53:58Z

`git remote -v` (`--verbose`) lists down the names of remotes along with their URLs. It would be beneficial for users to also specify the filter types for promisor remotes. Something like this - origin remote-url (fetch) [blob:none] origin remote-url (push) Teach `git remote -v` to also specify the filters for promisor remotes. Closes: https://github.com/gitgitgadget/git/issues/1211 Signed-off-by: Abhradeep Chakraborty Signed-off-by: Junio C Hamano

builtin/remote.c: show progress when renaming remote references

2022-03-03T22:44:05Z

When renaming a remote, Git needs to rename all remote tracking references to the remote's new name (e.g., renaming "refs/remotes/old/foo" to "refs/remotes/new/foo" when renaming a remote from "old" to "new"). This can be somewhat slow when there are many references to rename, since each rename is done in a separate call to rename_ref() as opposed to grouping all renames together into the same transaction. It would be nice to execute all renames as a single transaction, but there is a snag: the reference transaction backend doesn't support renames during a transaction (only individually, via rename_ref()). The reasons there are described in more detail in [1], but the main problem is that in order to preserve the existing reflog, it must be moved while holding both locks (i.e., on "oldname" and "newname"), and the ref transaction code doesn't support inserting arbitrary actions into the middle of a transaction like that. As an aside, adding support for this to the ref transaction code is less straightforward than inserting both a ref_update() and ref_delete() call into the same transaction. rename_ref()'s special handling to detect D/F conflicts would need to be rewritten for the transaction code if we wanted to proactively catch D/F conflicts when renaming a reference during a transaction. The reftable backend could support this much more readily because of its lack of D/F conflicts. Instead of a more complex modification to the ref transaction code, display a progress meter when running verbosely in order to convince the user that Git is doing work while renaming a remote. This is mostly done as-expected, with the minor caveat that we intentionally count symrefs renames twice, since renaming a symref takes place over two separate calls (one to delete the old one, and another to create the new one). [1]: https://lore.kernel.org/git/572367B4.4050207@alum.mit.edu/ Suggested-by: brian m. carlson Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

doc: uniformize placeholders' case

2021-11-09T17:39:11Z

URL being an acronym, it deserves to be kept uppercase. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

remote: add meaningful exit code on missing/existing

2020-10-27T18:40:33Z

Change the exit code for the likes of "git remote add/rename" to exit with 2 if the remote in question doesn't exist, and 3 if it does. Before we'd just die() and exit with the general 128 exit code. This changes the output message from e.g.: fatal: remote origin already exists. To: error: remote origin already exists. Which I believe is a feature, since we generally use "fatal" for the generic errors, and "error" for the more specific ones with a custom exit code, but this part of the change may break code that already relies on stderr parsing (not that we ever supported that...). The motivation for this is a discussion around some code in GitLab's gitaly which wanted to check this, and had to parse stderr to do so: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2695 It's worth noting as an aside that a method of checking this that doesn't rely on that is to check with "git config" whether the value in question does or doesn't exist. That introduces a TOCTOU race condition, but on the other hand this code (e.g. "git remote add") already has a TOCTOU race. We go through the config.lock for the actual setting of the config, but the pseudocode logic is: read_config(); check_config_and_arg_sanity(); save_config(); So e.g. if a sleep() is added right after the remote_is_configured() check in add() we'll clobber remote.NAME.url, and add another (usually duplicate) remote.NAME.fetch entry (and other values, depending on invocation). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

doc: git-remote fix ups

2020-10-08T21:01:18Z

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

doc: promote "git switch"

2019-04-02T04:57:00Z

The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'nd/remote-update-doc'

2018-06-04T12:39:49Z

"git remote update" can take both a single remote nickname and a nickname for remote groups, but only one of them was documented. * nd/remote-update-doc: remote: doc typofix remote.txt: update documentation for 'update' command

remote: doc typofix

2018-06-04T11:04:33Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

remote.txt: update documentation for 'update' command

2018-06-01T01:46:03Z

Commit b344e1614b (git remote update: Fallback to remote if group does not exist - 2009-04-06) lets "git remote update" accept individual remotes as well. Previously this command only accepted remote groups. The commit updates the command syntax but not the actual document of this subcommand. Update it. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano