summaryrefslogtreecommitdiff
path: root/Documentation/git-push.txt
AgeCommit message (Collapse)AuthorFilesLines
2015-03-28Merge branch 'ph/push-doc-cas'Libravatar Junio C Hamano1-8/+6
* ph/push-doc-cas: git-push.txt: clean up force-with-lease wording
2015-03-26git-push.txt: clean up force-with-lease wordingLibravatar Phil Hord1-8/+6
The help text for the --force-with-lease option to git-push does not parse cleanly. Clean up the wording and syntax to be more sensible. Also remove redundant information in the "--force-with-lease alone" description. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23Merge branch 'jk/push-config'Libravatar Junio C Hamano1-1/+4
Restructure "git push" codepath to make it easier to add new configuration bits and then add push.followTags configuration that turns --follow-tags option on by default. * jk/push-config: push: allow --follow-tags to be set by config push.followTags cmd_push: pass "flags" pointer to config callback cmd_push: set "atomic" bit directly git_push_config: drop cargo-culted wt_status pointer
2015-03-14push: allow --follow-tags to be set by config push.followTagsLibravatar Dave Olszewski1-1/+4
Signed-off-by: Dave Olszewski <cxreg@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17Merge branch 'mg/push-repo-option-doc'Libravatar Junio C Hamano1-16/+2
The "git push" documentation made the "--repo=<there>" option easily misunderstood. * mg/push-repo-option-doc: git-push.txt: document the behavior of --repo
2015-02-11Merge branch 'sb/atomic-push'Libravatar Junio C Hamano1-1/+6
"git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair. * sb/atomic-push: Document receive.advertiseatomic t5543-atomic-push.sh: add basic tests for atomic pushes push.c: add an --atomic argument send-pack.c: add --atomic command line argument send-pack: rename ref_update_to_be_sent to check_to_send_update receive-pack.c: negotiate atomic push support receive-pack.c: add execute_commands_atomic function receive-pack.c: move transaction handling in a central place receive-pack.c: move iterating over all commands outside execute_commands receive-pack.c: die instead of error in case of possible future bug receive-pack.c: shorten the execute_commands loop over all commands
2015-01-28git-push.txt: document the behavior of --repoLibravatar Michael J Gruber1-16/+2
As per the code, the --repo <repo> option is equivalent to the <repo> argument to 'git push', but somehow it was documented as something that is more than that. [It exists for historical reasons, back from the time when options had to come before arguments.] Say so. [But not that.] Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07push.c: add an --atomic argumentLibravatar Ronnie Sahlberg1-1/+6
Add a command line argument to the git push command to request atomic pushes. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-12Merge branch 'po/everyday-doc'Libravatar Junio C Hamano1-1/+1
* po/everyday-doc: Documentation: change "gitlink" typo in git-push
2014-11-17Documentation: change "gitlink" typo in git-pushLibravatar brian m. carlson1-1/+1
The git-push manual page used "gitlink" in one place instead of "linkgit". Fix this so the link renders correctly. Noticed-by: Dan Allen <dan.j.allen@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16Merge branch 'po/everyday-doc'Libravatar Junio C Hamano1-1/+1
"git help everyday" to show the Everyday Git document. * po/everyday-doc: doc: add 'everyday' to 'git help' doc: Makefile regularise OBSOLETE_HTML list building doc: modernise everyday.txt wording and format in man page style
2014-10-10doc: add 'everyday' to 'git help'Libravatar Philip Oakley1-1/+1
The "Everyday GIT With 20 Commands Or So" is not accessible via the Git help system. Move everyday.txt to giteveryday.txt so that "git help everyday" works, and create a new placeholder file everyday.html to refer people who follow existing URLs to the updated location. giteveryday.txt now formats well with AsciiDoc as a man page and refreshed content to a more command modern style. Add 'everyday' to the help --guides list and update git(1) and 5 other links to giteveryday. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-08Merge branch 'jc/push-cert'Libravatar Junio C Hamano1-1/+8
Allow "git push" request to be signed, so that it can be verified and audited, using the GPG signature of the person who pushed, that the tips of branches at a public repository really point the commits the pusher wanted to, without having to "trust" the server. * jc/push-cert: (24 commits) receive-pack::hmac_sha1(): copy the entire SHA-1 hash out signed push: allow stale nonce in stateless mode signed push: teach smart-HTTP to pass "git push --signed" around signed push: fortify against replay attacks signed push: add "pushee" header to push certificate signed push: remove duplicated protocol info send-pack: send feature request on push-cert packet receive-pack: GPG-validate push certificates push: the beginning of "git push --signed" pack-protocol doc: typofix for PKT-LINE gpg-interface: move parse_signature() to where it should be gpg-interface: move parse_gpg_output() to where it should be send-pack: clarify that cmds_sent is a boolean send-pack: refactor inspecting and resetting status and sending commands send-pack: rename "new_refs" to "need_pack_data" receive-pack: factor out capability string generation send-pack: factor out capability string generation send-pack: always send capabilities send-pack: refactor decision to send update per ref send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher ...
2014-09-15push: the beginning of "git push --signed"Libravatar Junio C Hamano1-1/+8
While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it does not mean I want to push it out to my 'master' branch---it is likely that I only want it in 'maint', so the signature on the object alone is insufficient. The only assurance to you that 'maint' points at what I wanted to place there comes from your trust on the hosting site and my authentication with it, which cannot easily audited later. Introduce a mechanism that allows you to sign a "push certificate" (for the lack of better name) every time you push, asserting that what object you are pushing to update which ref that used to point at what other object. Think of it as a cryptographic protection for ref updates, similar to signed tags/commits but working on an orthogonal axis. The basic flow based on this mechanism goes like this: 1. You push out your work with "git push --signed". 2. The sending side learns where the remote refs are as usual, together with what protocol extension the receiving end supports. If the receiving end does not advertise the protocol extension "push-cert", an attempt to "git push --signed" fails. Otherwise, a text file, that looks like the following, is prepared in core: certificate version 0.1 pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700 7339ca65... 21580ecb... refs/heads/master 3793ac56... 12850bec... refs/heads/next The file begins with a few header lines, which may grow as we gain more experience. The 'pusher' header records the name of the signer (the value of user.signingkey configuration variable, falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the certificate generation. After the header, a blank line follows, followed by a copy of the protocol message lines. Each line shows the old and the new object name at the tip of the ref this push tries to update, in the way identical to how the underlying "git push" protocol exchange tells the ref updates to the receiving end (by recording the "old" object name, the push certificate also protects against replaying). It is expected that new command packet types other than the old-new-refname kind will be included in push certificate in the same way as would appear in the plain vanilla command packets in unsigned pushes. The user then is asked to sign this push certificate using GPG, formatted in a way similar to how signed tag objects are signed, and the result is sent to the other side (i.e. receive-pack). In the protocol exchange, this step comes immediately before the sender tells what the result of the push should be, which in turn comes before it sends the pack data. 3. When the receiving end sees a push certificate, the certificate is written out as a blob. The pre-receive hook can learn about the certificate by checking GIT_PUSH_CERT environment variable, which, if present, tells the object name of this blob, and make the decision to allow or reject this push. Additionally, the post-receive hook can also look at the certificate, which may be a good place to log all the received certificates for later audits. Because a push certificate carry the same information as the usual command packets in the protocol exchange, we can omit the latter when a push certificate is in use and reduce the protocol overhead. This however is not included in this patch to make it easier to review (in other words, the series at this step should never be released without the remainder of the series, as it implements an interim protocol that will be incompatible with the final one). As such, the documentation update for the protocol is left out of this step. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-04Merge branch 'tf/maint-doc-push'Libravatar Junio C Hamano1-1/+1
* tf/maint-doc-push: git-push: fix link in man page
2014-07-31git-push: fix link in man pageLibravatar Tony Finch1-1/+1
Signed-off-by: Tony Finch <dot@dotat.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-08Merge branch 'jl/nor-or-nand-and'Libravatar Junio C Hamano1-1/+1
Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-07Merge branch 'jc/push-2.0-default-to-simple'Libravatar Junio C Hamano1-4/+6
Finally update the "git push" default behaviour to "simple".
2013-12-04push: use remote.$name.push as a refmapLibravatar Junio C Hamano1-2/+7
Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17Merge branch 'rh/ishes-doc'Libravatar Junio C Hamano1-1/+1
We liberally use "committish" and "commit-ish" (and "treeish" and "tree-ish"); as these are non-words, let's unify these terms to their dashed form. More importantly, clarify the documentation on object peeling using these terms. * rh/ishes-doc: glossary: fix and clarify the definition of 'ref' revisions.txt: fix and clarify <rev>^{<type>} glossary: more precise definition of tree-ish (a.k.a. treeish) use 'commit-ish' instead of 'committish' use 'tree-ish' instead of 'treeish' glossary: define commit-ish (a.k.a. committish) glossary: mention 'treeish' as an alternative to 'tree-ish'
2013-09-04use 'commit-ish' instead of 'committish'Libravatar Richard Hansen1-1/+1
Replace 'committish' in documentation and comments with 'commit-ish' to match gitglossary(7) and to be consistent with 'tree-ish'. The only remaining instances of 'committish' are: * variable, function, and macro names * "(also committish)" in the definition of commit-ish in gitglossary[7] Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22remote.c: add command line option parser for "--force-with-lease"Libravatar Junio C Hamano1-11/+66
Update "git push" and "git send-pack" to parse this commnd line option. The intended sematics is: * "--force-with-lease" alone, without specifying the details, will protect _all_ remote refs that are going to be updated by requiring their current value to be the same as some reasonable default, unless otherwise specified; * "--force-with-lease=refname", without specifying the expected value, will protect that refname, if it is going to be updated, by requiring its current value to be the same as some reasonable default. * "--force-with-lease=refname:value" will protect that refname, if it is going to be updated, by requiring its current value to be the same as the specified value; and * "--no-force-with-lease" will cancel all the previous --force-with-lease on the command line. For now, "some reasonable default" is tentatively defined as "the value of the remote-tracking branch we have for the ref of the remote being updated", and it is an error if we do not have such a remote-tracking branch. But this is known to be fragile, its use is not yet recommended, and hopefully we will find more reasonable default as we gain experience with this feature. The manual marks the feature as experimental unless the expected value is specified explicitly for this reason. Because the command line options are parsed _before_ we know which remote we are pushing to, there needs further processing to the parsed data after we instantiate the transport object to: * expand "refname" given by the user to a full refname to be matched with the list of "struct ref" used in match_push_refs() and set_ref_status_for_push(); and * learning the actual local ref that is the remote-tracking branch for the specified remote ref. Further, some processing need to be deferred until we find the set of remote refs and match_push_refs() returns in order to find the ones that need to be checked after explicit ones have been processed for "--force-with-lease" (no specific details). These post-processing will be the topic of the next patch. This option was originally called "cas" (for "compare and swap"), the name which nobody liked because it was too technical. The second attempt called it "lockref" (because it is conceptually like pushing after taking a lock) but the word "lock" was hated because it implied that it may reject push by others, which is not the way this option works. This round calls it "force-with-lease". You assume you took the lease on the ref when you fetched to decide what the rebased history should be, and you can push back only if the lease has not been broken. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'mm/push-force-is-dangerous'Libravatar Junio C Hamano1-0/+9
* mm/push-force-is-dangerous: Documentation/git-push.txt: explain better cases where --force is dangerous
2013-06-18push: switch default from "matching" to "simple"Libravatar Junio C Hamano1-11/+14
We promised to change the behaviour of lazy "git push [there]" that does not say what to push on the command line from "matching" to "simple" in Git 2.0. This finally flips that bit. Helped-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18Documentation/git-push.txt: explain better cases where --force is dangerousLibravatar Matthieu Moy1-0/+9
The behavior of "git push --force" is rather clear when it updates only one remote ref, but running it when pushing several branches can really be dangerous. Warn the users a bit more and give them the alternative to push only one branch. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05Merge branch 'tr/push-no-verify-doc'Libravatar Junio C Hamano1-1/+6
"git push --[no-]verify" was not documented. * tr/push-no-verify-doc: Document push --no-verify
2013-05-23Document push --no-verifyLibravatar Thomas Rast1-1/+6
ec55559 (push: Add support for pre-push hooks, 2013-01-13) forgot to add a note to git-push(1) about the new --no-verify option. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-17documentation: trivial style cleanupsLibravatar Felipe Contreras1-2/+1
White-spaces, missing braces, standardize --[no-]foo. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-26Merge branch 'jc/maint-push-refspec-default-doc' into maintLibravatar Junio C Hamano1-9/+14
* jc/maint-push-refspec-default-doc: Documentation/git-push: clarify the description of defaults
2013-03-25Merge branch 'jc/push-follow-tag'Libravatar Junio C Hamano1-1/+7
The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out. * jc/push-follow-tag: push: --follow-tags commit.c: use clear_commit_marks_many() in in_merge_bases_many() commit.c: add in_merge_bases_many() commit.c: add clear_commit_marks_many()
2013-03-21Merge branch 'jc/maint-push-refspec-default-doc'Libravatar Junio C Hamano1-9/+14
Clarify in the documentation "what" gets pushed to "where" when the command line to "git push" does not say these explicitly. * jc/maint-push-refspec-default-doc: Documentation/git-push: clarify the description of defaults
2013-03-08Documentation/git-push: clarify the description of defaultsLibravatar Junio C Hamano1-9/+14
We describe what gets pushed by default when the command line does not give any <refspec> under the bullet point of <refspec>. It is a bit unfriendly to expect users to read on <refspec> when they are not giving any in the first place. "What gets pushed" is determined by taking many factors (<refspec> argument being only one of them) into account, and is a property of the entire command, not an individual argument. Also we do not describe "Where the push goes" when the command line does not say. Give the description on "what gets pushed to where" upfront before explaining individual arguments and options. Also update the description of <refspec> to say what it is, what it is used for, before explaining what shape it takes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05push: --follow-tagsLibravatar Junio C Hamano1-1/+7
The new option "--follow-tags" tells "git push" to push annotated tags that are missing from the other side and that can be reached by the history that is otherwise pushed out. For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the commit at your current HEAD and nothing else. With this option, you would also push all annotated tags that can be reached from that commit to the other side. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-4/+4
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05Merge branch 'cr/push-force-tag-update'Libravatar Junio C Hamano1-4/+5
Require "-f" for push to update a tag, even if it is a fast-forward. * cr/push-force-tag-update: push: allow already-exists advice to be disabled push: rename config variable for more general use push: cleanup push rules comment push: clarify rejection of update to non-commit-ish push: require force for annotated tags push: require force for refs under refs/tags/ push: flag updates that require force push: keep track of "update" state separately push: add advice for rejected tag reference push: return reject reasons as a bitset
2012-12-02push: require force for annotated tagsLibravatar Chris Rorvick1-5/+5
Do not allow fast-forwarding of references that point to a tag object. Updating from a tag is potentially destructive since it would likely leave the tag dangling. Disallowing updates to a tag also makes sense semantically and is consistent with the behavior of lightweight tags. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: require force for refs under refs/tags/Libravatar Chris Rorvick1-5/+6
References are allowed to update from one commit-ish to another if the former is an ancestor of the latter. This behavior is oriented to branches which are expected to move with commits. Tag references are expected to be static in a repository, though, thus an update to something under refs/tags/ should be rejected unless the update is forced. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-27Documentation/git-push.txt: clarify the "push from satellite" workflowLibravatar Junio C Hamano1-2/+14
The context of the example to push into refs/remotes/satellite/ hierarchy of the other repository needs to be spelled out explicitly for the value of this example to be fully appreciated. Make it so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-27Documentation: improve phrasing in git-push.txtLibravatar Mark Szepieniec1-1/+2
The current version contains the sentence: Further suppose that the other person already pushed changes leading to A back to the original repository you two obtained the original commit X. which doesn't parse for me; I've changed it to Further suppose that the other person already pushed changes leading to A back to the original repository from which you two obtained the original commit X. Signed-off-by: Mark Szepieniec <mszepien@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-18Merge branch 'mm/maint-doc-remote-tracking' into maintLibravatar Junio C Hamano1-1/+1
Update "remote tracking branch" in the documentation to "remote-tracking branch". * mm/maint-doc-remote-tracking: Documentation: remote tracking branch -> remote-tracking branch
2012-11-04Merge branch 'mm/maint-doc-remote-tracking'Libravatar Jeff King1-1/+1
We long ago hyphenated "remote-tracking branch"; this catches some new instances added since then. * mm/maint-doc-remote-tracking: Documentation: remote tracking branch -> remote-tracking branch
2012-10-25Documentation: remote tracking branch -> remote-tracking branchLibravatar Matthieu Moy1-1/+1
This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2 2010, Replace "remote tracking" with "remote-tracking"), but new instances of remote tracking (without dash) were introduced in the meantime. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Jeff King <peff@peff.net>
2012-10-02Documentation: mention `push.default` in git-push.txtLibravatar Ramkumar Ramachandra1-3/+7
It already is listed in the "git config" documentation, but people interested in pushing would first look at "git push" documentation. Noticed-by: David Glasser Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Fixed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'jk/doc-asciidoc-inline-literal'Libravatar Junio C Hamano1-7/+7
Our documentation was written for an ancient version of AsciiDoc, making the source not very readable. By Jeff King * jk/doc-asciidoc-inline-literal: docs: stop using asciidoc no-inline-literal
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-7/+7
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24Merge branch 'hv/submodule-recurse-push'Libravatar Junio C Hamano1-4/+10
"git push --recurse-submodules" learns to optionally look into the histories of submodules bound to the superproject and push them out. By Heiko Voigt * hv/submodule-recurse-push: push: teach --recurse-submodules the on-demand option Refactor submodule push check to use string list instead of integer Teach revision walking machinery to walk multiple times sequencially
2012-03-30push: teach --recurse-submodules the on-demand optionLibravatar Heiko Voigt1-4/+10
When using this option git will search for all submodules that have changed in the revisions to be send. It will then try to push the currently checked out branch of each submodule. This helps when a user has finished working on a change which involves submodules and just wants to push everything in one go. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-22push: add '--prune' optionLibravatar Felipe Contreras1-1/+9
When pushing groups of refs to a remote, there is no simple way to remove old refs that still exist at the remote that is no longer updated from us. This will allow us to remove such refs from the remote. With this change, running this command $ git push --prune remote refs/heads/*:refs/remotes/laptop/* removes refs/remotes/laptop/foo from the remote if we do not have branch "foo" locally anymore. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-02Merge branch 'fg/submodule-ff-check-before-push'Libravatar Junio C Hamano1-0/+6
* fg/submodule-ff-check-before-push: push: Don't push a repository with unpushed submodules