In such a case only a warning is printed, such as: warning: The global configuration remote.pushDefault in: However remote.pushDefault needs a more gentle approach, as this may be set in a non-repo configuration file. Git already renames or removes any branch.remote and branch.pushRemote configurations if their value is X. When renaming a remote with git remote rename X Y Git already renames/removes any config values from branch.remote = XĪs branch.pushRemote also names a remote, it now also renames or removes these config values from branch.pushRemote = XĪnd: remote rename/remove: gently handle remote.pushDefault config When renaming or removing a remote with git remote rename X Y (Merged by Junio C Hamano - gitster - in commit d0038f4, ) remote rename/remove: handle branch.pushRemote config values See commit b3fd6cb (), and commit f2a2327, commit 923d4a5, commit ceff1a1, commit 1a83068, commit 88f8576 () by Bert Wesarg ( bertwesarg). branch.remote) whose value used to be X to Y. With Git 2.26 (Q1 2020), " git remote rename X Y" needs to adjust configuration variables (e.g. Repository), " git remote rename" and other commands misinterpretedĪnd behaved as if such a non-existing remote actually existed. May not actually be " origin" remote defined in a particular Git " " set to true, even though there may or With anticipatory tweaking for remotes defined in ~/.gitconfig (e.g. (Merged by Junio C Hamano - gitster - in commit fe575f0, ) remote rename: more carefully determine whether a remote is configured That is fixed in Git 2.12 (Q1 2017): See commit e459b07, commit af5bacf () by Johannes Schindelin ( dscho). This seems very simple but was very difficult to find and test.Be aware that until Git 2.11, git remote rename might try to rename a non-existing remote! The pack file then contains a 20 byte SHA hash of that message. Git pack file has a format consisting of a 4 character header "PACK" followed by the version (2 or 3) and the number of objects, both encoded in network byte order. If no refs are provided, git pack-ref will exit without creating a packfile rather than create one with zero items. The logic for building the messages and packfile and ending them are all hiddne behind a single api function.
The closest is git send_pack, which uses git pack-ref to create the pack file to send with the reference sha messages. This ability is not exposed anywhere in the git libraries. It is possible to create and construct a valid packfile containing zero entries. Then delete old branch which will also close the old pull-request. When creating a branch, a normal PACK file is created showing the state of the current repository. Best solution (for Github) is probably to create a new branch and new pull request, post a comment to old pull-request that it was 'closed in favor of NEW' and 'continuation of OLD' to new one. In reality, git push and git send-pack do not include a PACK file at all when sending a delete command. The documentation for the git message protocol specify that an empty pack file must be sent when deleting a branch. Message in pack_line formatĬonnects to remote Verified that exists and does not. The blank message of 0004 is not allowed.Ġ000 is used as a sync message. This can also be accomplished using -verbose or -quiet. See the documentation for git send-pack for more details.Ĭhoose an alternate ssh binary. Takes a string argument representing an alternate git-receive-pack exeutable to run on the remote host. The server then responds with an "unpack ok" message, followed by and "ok " message for each branch referenced in the sent message. This messages is encoded in pack_line format and sent to the remote along with a specially crafted empty_pack_file. This program then crafts a message to create the new branch and delete the old branch. This program parses the welcome message and extracts the SHA for and verifies that does not exist. The remote will ignore any input sent before this message is completed. Only ssh format repositories are supported : connection, the remote sends a welcome message contraining the SHA for each branch. This works similarly to the low-level command git upload-pack, except that git rename-remote-branch creates and sends an empty PACK file. Git rename-remote-branch renames a branch in a remote repository without requiring a local checkout or downloading refs. receive-pack-git override the executable run on the remote side. verbose|-v increase verbosity (can be used multiple times)
0 kommentar(er)
