path: root/builtin/push.c
AgeCommit message (Collapse)Author
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: 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-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 <>
2012-12-03push: allow already-exists advice to be disabledChris Rorvick
Add 'advice.pushAlreadyExists' option to disable the advice shown when an update is rejected for a reference that is not allowed to update at all (verses those that are allowed to fast-forward.) Signed-off-by: Chris Rorvick <> Signed-off-by: Junio C Hamano <>
2012-12-03push: rename config variable for more general useChris Rorvick
The 'pushNonFastForward' advice config can be used to squelch several instances of push-related advice. Rename it to 'pushUpdateRejected' to cover other reject scenarios that are unrelated to fast-forwarding. Retain the old name for compatibility. Signed-off-by: Chris Rorvick <> Signed-off-by: Junio C Hamano <>
2012-12-02push: require force for refs under refs/tags/Chris Rorvick
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 <> Signed-off-by: Junio C Hamano <>
2012-12-02push: add advice for rejected tag referenceChris Rorvick
Advising the user to fetch and merge only makes sense if the rejected reference is a branch. If none of the rejections are for branches, just tell the user the reference already exists. Signed-off-by: Chris Rorvick <> Signed-off-by: Junio C Hamano <>
2012-12-02push: return reject reasons as a bitsetChris Rorvick
Pass all rejection reasons back from transport_push(). The logic is simpler and more flexible with regard to providing useful feedback. Signed-off-by: Chris Rorvick <> Signed-off-by: Junio C Hamano <>
2012-09-07Merge branch 'nd/i18n-parseopt-help'Junio C Hamano
A lot of i18n mark-up for the help text from "git <cmd> -h". * nd/i18n-parseopt-help: (66 commits) Use imperative form in help usage to describe an action Reduce translations by using same terminologies i18n: write-tree: mark parseopt strings for translation i18n: verify-tag: mark parseopt strings for translation i18n: verify-pack: mark parseopt strings for translation i18n: update-server-info: mark parseopt strings for translation i18n: update-ref: mark parseopt strings for translation i18n: update-index: mark parseopt strings for translation i18n: tag: mark parseopt strings for translation i18n: symbolic-ref: mark parseopt strings for translation i18n: show-ref: mark parseopt strings for translation i18n: show-branch: mark parseopt strings for translation i18n: shortlog: mark parseopt strings for translation i18n: rm: mark parseopt strings for translation i18n: revert, cherry-pick: mark parseopt strings for translation i18n: rev-parse: mark parseopt strings for translation i18n: reset: mark parseopt strings for translation i18n: rerere: mark parseopt strings for translation i18n: status: mark parseopt strings for translation i18n: replace: mark parseopt strings for translation ...
2012-08-27Merge branch 'mm/push-default-switch-warning'Junio C Hamano
In the next major release, we will switch "git push [$there]" that does not say what to push from the traditional "matching" to the updated "simple" semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch (all other cases will error out). * mm/push-default-switch-warning: push: start warning upcoming default change for push.default
2012-08-22Use imperative form in help usage to describe an actionNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-08-20i18n: push: mark parseopt strings for translationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-06-25push: start warning upcoming default change for push.defaultMatthieu Moy
In preparation for flipping the default to the "simple" mode from the "matching" mode that is the historical default, start warning users when they rely on unconfigured "git push" to default to the "matching" mode. Also, advertise for 'simple' where 'current' and 'upstream' are advised. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2012-05-02Merge branch 'mm/simple-push'Junio C Hamano
New users tend to work on one branch at a time and push the result out. The current and upstream modes of push is a more suitable default mode than matching mode for these people, but neither is surprise-free depending on how the project is set up. Introduce a "simple" mode that is a subset of "upstream" but only works when the branch is named the same between the remote and local repositories. The plan is to make it the new default when push.default is not configured. By Matthieu Moy (5) and others * mm/simple-push: push.default doc: explain simple after upstream push: document the future default change for push.default (matching -> simple) t5570: use explicit push refspec push: introduce new push.default mode "simple" add helper functions Undocument deprecated alias 'push.default=tracking' Documentation: explain push.default option a bit more
2012-04-24push: introduce new push.default mode "simple"Matthieu Moy
When calling "git push" without argument, we want to allow Git to do something simple to explain and safe. push.default=matching is unsafe when used to push to shared repositories, and hard to explain to beginners in some contexts. It is debatable whether 'upstream' or 'current' is the safest or the easiest to explain, so introduce a new mode called 'simple' that is the intersection of them: push to the upstream branch, but only if it has the same name remotely. If not, give an error that suggests the right command to push explicitely to 'upstream' or 'current'. A question is whether to allow pushing when no upstream is configured. An argument in favor of allowing the push is that it makes the new mode work in more cases. On the other hand, refusing to push when no upstream is configured encourages the user to set the upstream, which will be beneficial on the next pull. Lacking better argument, we chose to deny the push, because it will be easier to change in the future if someone shows us wrong. Original-patch-by: Jeff King <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2012-04-24Merge branch 'hv/submodule-recurse-push'Junio C Hamano
"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-04-20Merge branch 'ct/advise-push-default'Junio C Hamano
Break down the cases in which "git push" fails due to non-ff into three categories, and give separate advise messages for each case. By Christopher Tiwald (2) and Jeff King (1) * ct/advise-push-default: Fix httpd tests that broke when non-ff push advice changed clean up struct ref's nonfastforward field push: Provide situational hints for non-fast-forward errors
2012-04-05push: error out when the "upstream" semantics does not make senseJunio C Hamano
The user can say "git push" without specifying any refspec. When using the "upstream" semantics via the push.default configuration, the user wants to update the "upstream" branch of the current branch, which is the branch at a remote repository the current branch is set to integrate with, with this command. However, there are cases that such a "git push" that uses the "upstream" semantics does not make sense: - The current branch does not have branch.$name.remote configured. By definition, "git push" that does not name where to push to will not know where to push to. The user may explicitly say "git push $there", but again, by definition, no branch at repository $there is set to integrate with the current branch in this case and we wouldn't know which remote branch to update. - The current branch does have branch.$name.remote configured, but it does not specify branch.$name.merge that names what branch at the remote this branch integrates with. "git push" knows where to push in this case (or the user may explicitly say "git push $remote" to tell us where to push), but we do not know which remote branch to update. - The current branch does have its remote and upstream branch configured, but the user said "git push $there", where $there is not the remote named by "branch.$name.remote". By definition, no branch at repository $there is set to integrate with the current branch in this case, and this push is not meant to update any branch at the remote repository $there. The first two cases were already checked correctly, but the third case was not checked and we ended up updating the branch named branch.$name.merge at repository $there, which was totally bogus. Signed-off-by: Junio C Hamano <>
2012-03-30push: teach --recurse-submodules the on-demand optionHeiko Voigt
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 <> Mentored-by: Jens Lehmann <> Mentored-by: Heiko Voigt <> Signed-off-by: Junio C Hamano <>
2012-03-20push: Provide situational hints for non-fast-forward errorsChristopher Tiwald
Pushing a non-fast-forward update to a remote repository will result in an error, but the hint text doesn't provide the correct resolution in every case. Give better resolution advice in three push scenarios: 1) If you push your current branch and it triggers a non-fast-forward error, you should merge remote changes with 'git pull' before pushing again. 2) If you push to a shared repository others push to, and your local tracking branches are not kept up to date, the 'matching refs' default will generate non-fast-forward errors on outdated branches. If this is your workflow, the 'matching refs' default is not for you. Consider setting the 'push.default' configuration variable to 'current' or 'upstream' to ensure only your current branch is pushed. 3) If you explicitly specify a ref that is not your current branch or push matching branches with ':', you will generate a non-fast-forward error if any pushed branch tip is out of date. You should checkout the offending branch and merge remote changes before pushing again. Teach transport.c to recognize these scenarios and configure push.c to hint for them. If 'git push's default behavior changes or we discover more scenarios, extension is easy. Standardize on the advice API and add three new advice variables, 'pushNonFFCurrent', 'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these to 'false' will disable their affiliated advice. Setting 'pushNonFastForward' to false will disable all three, thus preserving the config option for users who already set it, but guaranteeing new users won't disable push advice accidentally. Based-on-patch-by: Junio C Hamano <> Signed-off-by: Christopher Tiwald <> Signed-off-by: Junio C Hamano <>
2012-02-27Merge branch 'fc/push-prune'Junio C Hamano
* fc/push-prune: push: add '--prune' option remote: refactor code into alloc_delete_ref() remote: reorganize check_pattern_match() remote: use a local variable in match_push_refs() Conflicts: builtin/push.c
2012-02-23push: add '--prune' optionFelipe Contreras
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 <> Signed-off-by: Junio C Hamano <>
2012-02-13push/fetch/clone --no-progress suppresses progress outputClemens Buchacher
By default, progress output is disabled if stderr is not a terminal. The --progress option can be used to force progress output anyways. Conversely, --no-progress does not force progress output. In particular, if stderr is a terminal, progress output is enabled. This is unintuitive. Change --no-progress to force output off. Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2011-08-21push: Don't push a repository with unpushed submodulesFredrik Gustafsson
When working with submodules it is easy to forget to push a submodule to the server but pushing a super-project that contains a commit for that submodule. The result is that the superproject points at a submodule commit that is not available on the server. This adds the option --recurse-submodules=check to push. When using this option git will check that all submodule commits that are about to be pushed are present on a remote of the submodule. To be able to use a combined diff, disabling a diff callback has been removed from combined-diff.c. Signed-off-by: Fredrik Gustafsson <> Mentored-by: Jens Lehmann <> Mentored-by: Heiko Voigt <> Signed-off-by: Junio C Hamano <>
2011-04-02Merge branch 'ab/i18n-st'Junio C Hamano
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/ t/
2011-03-20Merge branch 'jk/trace-sifter'Junio C Hamano
* jk/trace-sifter: trace: give repo_setup trace its own key add packet tracing debug code trace: add trace_strbuf trace: factor out "do we want to trace" logic trace: refactor to support multiple env variables trace: add trace_vprintf