path: root/builtin/push.c
AgeCommit message (Collapse)Author
2015-12-22push: don't mark options of recurse-submodules for translationRalf Thielow
Signed-off-by: Ralf Thielow <> Signed-off-by: Junio C Hamano <>
2015-12-04push: follow the "last one wins" convention for --recurse-submodulesMike Crowe
Use the "last one wins" convention for --recurse-submodules rather than treating conflicting options as an error. Also, fix the declaration of the file-scope recurse_submodules global variable to put it on a separate line. Signed-off-by: Mike Crowe <> Signed-off-by: Junio C Hamano <>
2015-11-20push: add recurseSubmodules config optionMike Crowe
The --recurse-submodules command line parameter has existed for some time but it has no config file equivalent. Following the style of the corresponding parameter for git fetch, let's invent push.recurseSubmodules to provide a default for this parameter. This also requires the addition of --recurse-submodules=no to allow the configuration to be overridden on the command line when required. The most straightforward way to implement this appears to be to make push use code in submodule-config in a similar way to fetch. Signed-off-by: Mike Crowe <> Signed-off-by: Jeff King <>
2015-08-19push: add a config option push.gpgSign for default signed pushesDave Borowitz
Signed-off-by: Dave Borowitz <> Signed-off-by: Junio C Hamano <>
2015-08-19push: support signing pushes iff the server supports itDave Borowitz
Add a new flag --sign=true (or --sign=false), which means the same thing as the original --signed (or --no-signed). Give it a third value --sign=if-asked to tell push and send-pack to send a push certificate if and only if the server advertised a push cert nonce. If not, warn the user that their push may not be as secure as they thought. Signed-off-by: Dave Borowitz <> Signed-off-by: Junio C Hamano <>
2015-03-14push: allow --follow-tags to be set by config push.followTagsDave Olszewski
Signed-off-by: Dave Olszewski <> Helped-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-02-17cmd_push: pass "flags" pointer to config callbackJeff King
This will let us manipulate any transport flags which have matching config options (there are none yet, but we will add one in the next patch). We could also just make "flags" a static file-scope global, but the result is a little confusing. We end up passing it along through do_push and push_with_options, each of which further munge it. Having slightly-differing versions of the flags variable available to those functions would probably cause more confusion than it is worth. Let's just keep the original local to cmd_push, and it can continue to pass it through the call-stack. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-02-17cmd_push: set "atomic" bit directlyJeff King
This makes the code shorter and more obvious by removing an unnecessary interim variable. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-02-16git_push_config: drop cargo-culted wt_status pointerJeff King
The push config callback does not expect any incoming data via the void pointer. And if it did, it would certainly not be a "struct wt_status". This probably got picked up accidentally in b945901 (push: heed user.signingkey for signed pushes, 2014-10-22), which copied the template for the config callback from builtin/commit.c. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-02-11Merge branch 'sb/atomic-push'Junio C Hamano
"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 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-08push.c: add an --atomic argumentRonnie Sahlberg
Add a command line argument to the git push command to request atomic pushes. Signed-off-by: Ronnie Sahlberg <> Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2014-12-12Merge branch 'jk/push-simple'Junio C Hamano
Git 2.0 was supposed to make the "simple" mode for the default of "git push", but it didn't. * jk/push-simple: push: truly use "simple" as default, not "upstream"
2014-12-12Merge branch 'rt/push-recurse-submodule-usage-string'Junio C Hamano
* rt/push-recurse-submodule-usage-string: builtin/push.c: fix description of --recurse-submodules option
2014-12-01push: truly use "simple" as default, not "upstream"Jeff King
The plan for the push.default transition had all along been to use the "simple" method rather than "upstream" as a default if the user did not specify their own push.default value. Commit 11037ee (push: switch default from "matching" to "simple", 2013-01-04) tried to implement that by moving PUSH_DEFAULT_UNSPECIFIED in our switch statement to fall-through to the PUSH_DEFAULT_SIMPLE case. When the commit that became 11037ee was originally written, that would have been enough. We would fall through to calling setup_push_upstream() with the "simple" parameter set to 1. However, it was delayed for a while until we were ready to make the transition in Git 2.0. And in the meantime, commit ed2b182 (push: change `simple` to accommodate triangular workflows, 2013-06-19) threw a monkey wrench into the works. That commit drops the "simple" parameter to setup_push_upstream, and instead checks whether the global "push_default" is PUSH_DEFAULT_SIMPLE. This is right when the user has explicitly configured push.default to simple, but wrong when we are a fall-through for the "unspecified" case. We never noticed because our push.default tests do not cover the case of the variable being totally unset; they only check the "simple" behavior itself. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-18builtin/push.c: fix description of --recurse-submodules optionRalf Thielow
The description of the option for argument "recurse-submodules" is marked for translation even if it expects the untranslated string and it's missing the option "on-demand" which was introduced in eb21c73 (2014-03-29, push: teach --recurse-submodules the on-demand option). Fix this by unmark the string for translation and add the missing option. Signed-off-by: Ralf Thielow <> Signed-off-by: Junio C Hamano <>
2014-10-24push: heed user.signingkey for signed pushesMichael J Gruber
push --signed promises to take user.signingkey as the signing key but fails to read the config. Make it do so. Signed-off-by: Michael J Gruber <> Signed-off-by: Junio C Hamano <>
2014-09-15push: the beginning of "git push --signed"Junio C Hamano
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 <> 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 <>
2014-06-20refactor skip_prefix to return a booleanJeff King
The skip_prefix() function returns a pointer to the content past the prefix, or NULL if the prefix was not found. While this is nice and simple, in practice it makes it hard to use for two reasons: 1. When you want to conditionally skip or keep the string as-is, you have to introduce a temporary variable. For example: tmp = skip_prefix(buf, "foo"); if (tmp) buf = tmp; 2. It is verbose to check the outcome in a conditional, as you need extra parentheses to silence compiler warnings. For example: if ((cp = skip_prefix(buf, "foo")) /* do something with cp */ Both of these make it harder to use for long if-chains, and we tend to use starts_with() instead. However, the first line of "do something" is often to then skip forward in buf past the prefix, either using a magic constant or with an extra strlen(3) (which is generally computed at compile time, but means we are repeating ourselves). This patch refactors skip_prefix() to return a simple boolean, and to provide the pointer value as an out-parameter. If the prefix is not found, the out-parameter is untouched. This lets you write: if (skip_prefix(arg, "foo ", &arg)) do_foo(arg); else if (skip_prefix(arg, "bar ", &arg)) do_bar(arg); Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-03-07Merge branch 'cc/starts-n-ends-with-endgame'Junio C Hamano
prefixcmp/suffixcmp are gone.
2014-03-07Merge branch 'gj/push-more-verbose-advice'Junio C Hamano
2014-03-07Merge branch 'jc/push-2.0-default-to-simple'Junio C Hamano
Finally update the "git push" default behaviour to "simple".
2013-12-27Merge branch 'jc/push-refmap'Junio C Hamano
Make "git push origin master" update the same ref that would be updated by our 'master' when "git push origin" (no refspecs) is run while the 'master' branch is checked out, which makes "git push" more symmetric to "git fetch" and more usable for the triangular workflow. * jc/push-refmap: push: also use "upstream" mapping when pushing a single ref push: use remote.$name.push as a refmap builtin/push.c: use strbuf instead of manual allocation
2013-12-04push: also use "upstream" mapping when pushing a single refJunio C Hamano
When the user is using the 'upstream' mode, these commands: $ git push $ git push origin would find the 'upstream' branch for the current branch, and then push the current branch to update it. However, pushing a single branch explicitly, i.e. $ git push origin $(git symbolic-ref --short HEAD) would not go through the same ref mapping process, and ends up updating the branch at 'origin' of the same name, which may not necessarily be the upstream of the branch being pushed. In the spirit similar to the previous one, map a colon-less refspec using the upstream mapping logic. Signed-off-by: Junio C Hamano <>
2013-12-04push: use remote.$name.push as a refmapJunio C Hamano
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 <>
2013-12-03builtin/push.c: use strbuf instead of manual allocationJunio C Hamano
The command line arguments given to "git push" are massaged into a list of refspecs in set_refspecs() function. This was implemented using xmalloc, strcpy and friends, but it is much easier to read if done using strbuf. Signed-off-by: Junio C Hamano <>
2013-11-13push: switch default from "matching" to "simple"Junio C Hamano
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 <> Signed-off-by: Junio C Hamano <>
2013-11-13push: enhance unspecified push default warningGreg Jacobson
When the unset push.default warning message is displayed this may be the first time many users encounter push.default. Explain in the warning message in a compact manner what push.default is and what the change means to the end-user to help the users decide. Signed-off-by: Greg Jacobson <> Helped-by: Jonathan Nieder <> Helped-by: Matthieu Moy <> Helped-by: Marc Branchaud <> Signed-off-by: Junio C Hamano <>
2013-09-11Merge branch 'nd/push-no-thin'Junio C Hamano
"git push --no-thin" was a no-op by mistake. * nd/push-no-thin: push: respect --no-thin
2013-09-09Merge branch 'jc/push-cas'Junio C Hamano
Allow a safer "rewind of the remote tip" push than blind "--force", by requiring that the overwritten remote ref to be unchanged since the new history to replace it was prepared. The machinery is more or less ready. The "--force" option is again the big red button to override any safety, thanks to J6t's sanity (the original round allowed --lockref to defeat --force). The logic to choose the default implemented here is fragile (e.g. "git fetch" after seeing a failure will update the remote-tracking branch and will make the next "push" pass, defeating the safety pretty easily). It is suitable only for the simplest workflows, and it may hurt users more than it helps them. * jc/push-cas: push: teach --force-with-lease to smart-http transport send-pack: fix parsing of --force-with-lease option t5540/5541: smart-http does not support "--force-with-lease" t5533: test "push --force-with-lease" push --force-with-lease: tie it all together push --force-with-lease: implement logic to populate old_sha1_expect[] remote.c: add command line option parser for "--force-with-lease" builtin/push.c: use OPT_BOOL, not OPT_BOOLEAN cache.h: move remote/connect API out of it
2013-09-04Merge branch 'sb/parseopt-boolean-removal'Junio C Hamano
Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary. * sb/parseopt-boolean-removal: revert: use the OPT_CMDMODE for parsing, reducing code checkout-index: fix negations of even numbers of -n config parsing options: allow one flag multiple times hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP branch, commit, name-rev: ease up boolean conditions checkout: remove superfluous local variable log, format-patch: parsing uses OPT__QUIET Replace deprecated OPT_BOOLEAN by OPT_BOOL Remove deprecated OPTION_BOOLEAN for parsing arguments
2013-08-13push: respect --no-thinNguyễn Thái Ngọc Duy
- From the beginning of push.c in 755225d, 2006-04-29, "thin" option was enabled by default but could be turned off with --no-thin. - Then Shawn changed the default to 0 in favor of saving server resources in a4503a1, 2007-09-09. --no-thin worked great. - One day later, in 9b28851 Daniel extracted some code from push.c to create transport.c. He (probably accidentally) flipped the default value from 0 to 1 in transport_get(). From then on --no-thin is effectively no-op because git-push still expects the default value to be false and only calls transport_set_option() when "thin" variable in push.c is true (which is unnecessary). Correct the code to respect --no-thin by calling transport_set_option() in both cases. receive-pack learns about --reject-thin-pack-for-testing option, which only is for testing purposes, hence no document update. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-07-29many small typofixesOndřej Bílka
Signed-off-by: Ondřej Bílka <> Reviewed-by: Marc Branchaud <> Signed-off-by: Junio C Hamano <>
2013-07-23push --force-with-lease: implement logic to populate old_sha1_expect[]Junio C Hamano
This plugs the push_cas_option data collected by the command line option parser to the transport system with a new function apply_push_cas(), which is called after match_push_refs() has already been called. At this point, we know which remote we are talking to, and what remote refs we are going to update, so we can fill in the details that may have been missing from the command line, such as (1) what abbreviated refname the user gave us matches the actual refname at the remote; and (2) which remote-tracking branch in our local repository to read the value of the object to expect at the remote. to populate the old_sha1_expect[] field of each of the remote ref. As stated in the documentation, the use of remote-tracking branch as the default is a tentative one, and we may come up with a better logic as we gain experience. Still nobody uses this information, which is the topic of the next patch. Signed-off-by: Junio C Hamano <>
2013-07-23remote.c: add command line option parser for "--force-with-lease"Junio C Hamano
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 <>
2013-07-12Merge branch 'jk/pull-to-integrate'Junio C Hamano
* jk/pull-to-integrate: pull: change the description to "integrate" changes push: avoid suggesting "merging" remote changes
2013-07-09builtin/push.c: use OPT_BOOL, not OPT_BOOLEANJunio C Hamano
The command line parser of "git push" for "--tags", "--delete", and "--thin" options still used outdated OPT_BOOLEAN. Because these options do not give escalating levels when given multiple times, they should use OPT_BOOL. Signed-off-by: Junio C Hamano <>
2013-07-07push: avoid suggesting "merging" remote changesJohn Keeping
With some workflows, it is more suitable to rebase on top of remote changes when a push does not fast-forward. Change the advice messages in git-push to suggest that a user "integrate the remote changes" instead of "merge the remote changes" to make this slightly clearer. Also change the suggested 'git pull' to 'git pull ...' to hint to users that they may want to add other parameters. Suggested-by: Philip Oakley <> Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-06-24push: change `simple` to accommodate triangular workflowsRamkumar Ramachandra
When remote.pushdefault or branch.<name>.pushremote is set to a remote that is different from where you usually fetch from (i.e. a triangular workflow), master@{u} != origin, and push.default is set to `upstream` or `simple` would fail with this error: $ git push fatal: You are pushing to remote 'origin', which is not the upstream of your current branch 'master', without telling me what to push to update which remote branch. The very name of "upstream" indicates that it is only suitable for use in central workflows; let us not even attempt to give it a new meaning in triangular workflows, and error out as before. However, the `simple` does not have to share this error. It is poised to be the default for Git 2.0, and we would like it to do something sensible in triangular workflows. Redefine "simple" as "safer upstream" for centralized workflow as before, but work as "current" for triangular workflow. We may want to make it "safer current", but that is a separate issue. Reported-by: Leandro Lucarella <> Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2013-06-18push: switch default from "matching" to "simple"Junio C Hamano
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 <> Signed-off-by: Junio C Hamano <>
2013-05-29push: make push.default = current use resolved HEADRamkumar Ramachandra
With this change, the output of the push (with push.default set to current) changes subtly from: $ git push ... * [new branch] HEAD -> push-current-head to: $ git push ... * [new branch] push-current-head -> push-current-head This patch was written with a different motivation. There is a problem unique to push.default = current: # on branch push-current-head $ git push # on another terminal $ git checkout master # return to the first terminal # the push tried to push master! This happens because the 'git checkout' on the second terminal races with the 'git push' on the first terminal. Although this patch does not solve the core problem (there is still no guarantee that 'git push' on the first terminal will resolve HEAD before 'git checkout' changes HEAD on the second), it works in practice. Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2013-05-29push: fail early with detached HEAD and currentRamkumar Ramachandra
Setting push.default to current adds the refspec "HEAD" for the transport layer to handle. If "HEAD" doesn't resolve to a branch (and since no refspec rhs is specified), the push fails after some time with a cryptic error message: $ git push error: unable to push to unqualified destination: HEAD The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to '' Fail early with a nicer error message: $ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use git push ram HEAD:<name-of-remote-branch> Just like in the upstream and simple cases. Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2013-05-29push: factor out the detached HEAD error messageRamkumar Ramachandra
With push.default set to upstream or simple, and a detached HEAD, git push prints the following error: $ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use git push ram HEAD:<name-of-remote-branch> This error is not unique to upstream or simple: current cannot push with a detached HEAD either. So, factor out the error string in preparation for using it in current. Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2013-04-02remote.c: introduce a way to have different remotes for fetch/pushRamkumar Ramachandra
Currently, do_push() in push.c calls remote_get(), which gets the configured remote for fetching and pushing. Replace this call with a call to pushremote_get() instead, a new function that will return the remote configured specifically for pushing. This function tries to work with the string pushremote_name, before falling back to the codepath of remote_get(). This patch has no visible impact, but serves to enable future patches to introduce configuration variables to set pushremote_name. For example, you can now do the following in handle_config(): if (!strcmp(key, "remote.pushdefault")) git_config_string(&pushremote_name, key, value); Then, pushes will automatically go to the remote specified by remote.pushdefault. Signed-off-by: Ramkumar Ramachandra <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-03-25Merge branch 'jc/push-follow-tag'Junio C Hamano
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-05push: --follow-tagsJunio C Hamano
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 <>
2013-02-04Merge branch 'jc/push-reject-reasons'Junio C Hamano
Improve error and advice messages given locally when "git push" refuses when it cannot compute fast-forwardness by separating these cases from the normal "not a fast-forward; merge first and push again" case. * jc/push-reject-reasons: push: finishing touches to explain REJECT_ALREADY_EXISTS better push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection reason push: further clean up fields of "struct ref"
2013-01-25push: finishing touches to explain REJECT_ALREADY_EXISTS betterJunio C Hamano
Now that "already exists" errors are given only when a push tries to update an existing ref in refs/tags/ hierarchy, we can say "the tag", instead of "the destination reference", and that is far easier to understand. Pointed out by Chris Rorvick. Signed-off-by: Junio C Hamano <>
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCEJunio C Hamano
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <>
2013-01-18push: Add support for pre-push hooksAaron Schrab
Add support for a pre-push hook which can be used to determine if the set of refs to be pushed is suitable for the target repository. The hook is run with two arguments specifying the name and location of the destination repository. Information about what is to be pushed is provided by sending lines of the following form to the hook's standard input: <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF If the hook exits with a non-zero status, the push will be aborted. This will allow the script to determine if the push is acceptable based on the target repository and branch(es), the commits which are to be pushed, and even the source branches in some cases. Signed-off-by: Aaron Schrab <> Signed-off-by: Junio C Hamano <>