summaryrefslogtreecommitdiff
path: root/builtin/push.c
AgeCommit message (Collapse)Author
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 <gitster@pobox.com>
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 <philipoakley@iee.org> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <leandro.lucarella@sociomantic.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 'git@github.com:artagnon/git' 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 <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <gitster@pobox.com>
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 <gitster@pobox.com>
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 <gitster@pobox.com>
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 <aaron@schrab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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" t5528-push-default.sh: 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 <peff@peff.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <gitster@pobox.com>
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 <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-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 <gitster@pobox.com> Signed-off-by: Christopher Tiwald <christiwald@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <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>
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/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
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
2011-03-10i18n: git-push "prevent you from losing" messageÆvar Arnfjörð Bjarmason
Gettextize the "To prevent you from losing history" message. A test in lib-httpd.sh and another in t5541-http-push.sh explicitly checked for this message. Change them to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10i18n: git-push basic messagesÆvar Arnfjörð Bjarmason
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08add packet tracing debug codeJeff King
This shows a trace of all packets coming in or out of a given program. This can help with debugging object negotiation or other protocol issues. To keep the code changes simple, we operate at the lowest level, meaning we don't necessarily understand what's in the packets. The one exception is a packet starting with "PACK", which causes us to skip that packet and turn off tracing (since the gigantic pack data will not be interesting to read, at least not in the trace format). We show both written and read packets. In the local case, this may mean you will see packets twice (written by the sender and read by the receiver). However, for cases where the other end is remote, this allows you to see the full conversation. Packet tracing can be enabled with GIT_TRACE_PACKET=<foo>, where <foo> takes the same arguments as GIT_TRACE. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-02push: better error message when no remote configuredMatthieu Moy
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-02push: better error messages when push.default = trackingMatthieu Moy
A common scenario is to create a new branch and push it (checkout -b && push [--set-upstream]). In this case, the user was getting "The current branch %s has no upstream branch.", which doesn't help much. Provide the user a command to push the current branch. To avoid the situation in the future, suggest --set-upstream. While we're there, also improve the error message in the "detached HEAD" case. We mention explicitly "detached HEAD" since this is the keyword to look for in documentations. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16push.default: Rename 'tracking' to 'upstream'Johan Herland
Users are sometimes confused with two different types of "tracking" behavior in Git: "remote-tracking" branches (e.g. refs/remotes/*/*) versus the merge/rebase relationship between a local branch and its @{upstream} (controlled by branch.foo.remote and branch.foo.merge config settings). When the push.default is set to 'tracking', it specifies that a branch should be pushed to its @{upstream} branch. In other words, setting push.default to 'tracking' applies only to the latter of the above two types of "tracking" behavior. In order to make this more understandable to the user, we rename the push.default == 'tracking' option to push.default == 'upstream'. push.default == 'tracking' is left as a deprecated synonym for 'upstream'. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-13Merge branch 'maint'Junio C Hamano
* maint: push: mention "git pull" in error message for non-fast forwards Standardize do { ... } while (0) style t/t7003: replace \t with literal tab in sed expression index-pack: Don't follow replace refs.
2010-08-13push: mention "git pull" in error message for non-fast forwardsMatthieu Moy
The message remains fuzzy to include "git pull", "git pull --rebase" and others, but directs the user to the simplest solution in the vast majority of cases. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-02builtin/push.c: remove useless temporary variableJared Hance
Creating a variable nr here to use throughout the function only to change refspec_nr to nr at the end, having not used refspec_nr the entire time, is rather pointless. Instead, simply increment refspec_nr. While at it, use ALLOC_GROW() instead of xrealloc(). Signed-off-by: Jared Hance <jaredhance@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-10Merge branch 'maint'Junio C Hamano
* maint: Let check_preimage() use memset() to initialize "struct checkout" fetch/push: fix usage strings
2010-03-15Merge branch 'tc/transport-verbosity'Junio C Hamano
* tc/transport-verbosity: transport: update flags to be in running order fetch and pull: learn --progress push: learn --progress transport->progress: use flag authoritatively clone: support multiple levels of verbosity push: support multiple levels of verbosity fetch: refactor verbosity option handling into transport.[ch] Documentation/git-push: put --quiet before --verbose Documentation/git-pull: put verbosity options before merge/fetch ones Documentation/git-clone: mention progress in -v Conflicts: transport.h
2010-03-15Merge branch 'ld/push-porcelain'Junio C Hamano
* ld/push-porcelain: t5516: Use test_cmp when appropriate git-push: add tests for git push --porcelain git-push: make git push --porcelain print "Done" git-push: send "To <remoteurl>" messages to the standard output in --porcelain mode git-push: fix an advice message so it goes to stderr Conflicts: transport.c