{"thread":{"id":"12204","subject":"[PATCH 2/3] Documentation/push: clarify matching refspec behavior","startedAt":"2008-02-19T16:25:22Z","lastAt":"2008-02-19T16:26:45Z","messageCount":2,"participants":["Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"69283","messageId":"20080219162522.GB30451@sigill.intra.peff.net","threadId":"12204","inReplyTo":"d9b18b1827a183e5b3b785a092605eab1ff4b6e7.1203438181.git.peff@peff.net","subject":"[PATCH 2/3] Documentation/push: clarify matching refspec behavior","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T16:25:22Z","receivedAt":"2008-02-19T16:25:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The previous text was correct, but it was easy to miss the\nfact that we are talking about \"matching\" refs. That is, the\ntext can be parsed as \"we push the union of the sets\nof remote and local heads\" and not \"we push the intersection\nof the sets of remote and local heads\". (The former actually\ndoesn't make sense if you think about it, since we don't\neven _have_ some of those heads). A careful reading would\nreveal the correct meaning, but it makes sense to be as\nexplicit as possible in documentation.\n\nWe also explicitly use and introduce the term \"matching\";\nthis is a term discussed on the list, and it seems useful\nto for users to be able to refer to this behavior by name.\n\nSigned-off-by: Jeff King \n---\n Documentation/git-push.txt | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 5f24944..650ee91 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -47,9 +47,9 @@ even if it does not result in a fast forward update.\n +\n Note: If no explicit refspec is found, (that is neither\n on the command line nor in any Push line of the\n-corresponding remotes file---see below), then all the\n-heads that exist both on the local side and on the remote\n-side are updated.\n+corresponding remotes file---see below), then \"matching\" heads are\n+pushed: for every head that exists on the local side, the remote side is\n+updated if a head of the same name already exists on the remote side.\n +\n `tag ` means the same as `refs/tags/:refs/tags/`.\n +\n-- \n1.5.4.1.143.ge7e51-dirty\n"},{"id":"69285","messageId":"20080219162645.GC30451@sigill.intra.peff.net","threadId":"12204","inReplyTo":"d9b18b1827a183e5b3b785a092605eab1ff4b6e7.1203438181.git.peff@peff.net","subject":"[PATCH 3/3] push: document the status output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-19T16:26:45Z","receivedAt":"2008-02-19T16:26:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The output was meant to be a balance of self-explanatory and\nterse. In case we have erred too far on the terse side, it\ndoesn't hurt to explain in more detail what each line means.\n\nSigned-off-by: Jeff King \n---\n Documentation/git-push.txt | 49 ++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 49 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 650ee91..3128170 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -108,6 +108,55 @@ the remote repository.\n \n include::urls-remotes.txt[]\n \n+OUTPUT\n+------\n+\n+The output of \"git push\" depends on the transport method used; this\n+section describes the output when pushing over the git protocol (either\n+locally or via ssh).\n+\n+The status of the push is output in tabular form, with each line\n+representing the status of a single ref. Each line is of the form:\n+\n+-------------------------------\n+ -> ()\n+-------------------------------\n+\n+flag::\n+\tA single character indicating the status of the ref. This is\n+\tblank for a successfully pushed ref, `!` for a ref that was\n+\trejected or failed to push, and '=' for a ref that was up to\n+\tdate and did not need pushing (note that the status of up to\n+\tdate refs is shown only when `git push` is running verbosely).\n+\n+summary::\n+\tFor a successfully pushed ref, the summary shows the old and new\n+\tvalues of the ref in a form suitable for using as an argument to\n+\t`git log` (this is `..` in most cases, and\n+\t`...` for forced non-fast forward updates). For a\n+\tfailed update, more details are given for the failure.\n+\tThe string `rejected` indicates that git did not try to send the\n+\tref at all (typically because it is not a fast forward). The\n+\tstring `remote rejected` indicates that the remote end refused\n+\tthe update; this rejection is typically caused by a hook on the\n+\tremote side. The string `remote failure` indicates that the\n+\tremote end did not report the successful update of the ref\n+\t(perhaps because of a temporary error on the remote side, a\n+\tbreak in the network connection, or other transient error).\n+\n+from::\n+\tThe name of the local ref being pushed, minus its\n+\t`refs//` prefix. In the case of deletion, the\n+\tname of the local ref is omitted.\n+\n+to::\n+\tThe name of the remote ref being updated, minus its\n+\t`refs//` prefix.\n+\n+reason::\n+\tA human-readable explanation. In the case of successfully pushed\n+\trefs, no explanation is needed. For a failed ref, the reason for\n+\tfailure is described.\n \n Examples\n --------\n-- \n1.5.4.1.143.ge7e51-dirty\n"}]}