git/builtin/push.c, branch v1.8.2.2

Merge branch 'jc/push-reject-reasons'

2013-02-04T18:25:04Z

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"

push: finishing touches to explain REJECT_ALREADY_EXISTS better

2013-01-25T07:28:50Z

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

push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE

2013-01-24T22:37:23Z

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

push: Add support for pre-push hooks

2013-01-18T19:13:22Z

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: SP SP SP 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

push: allow already-exists advice to be disabled

2012-12-03T16:04:09Z

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

push: rename config variable for more general use

2012-12-03T16:04:08Z

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

push: require force for refs under refs/tags/

2012-12-02T09:44:34Z

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

push: add advice for rejected tag reference

2012-12-02T09:39:50Z

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

push: return reject reasons as a bitset

2012-12-02T09:37:20Z

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

Merge branch 'nd/i18n-parseopt-help'

2012-09-07T18:09:09Z

A lot of i18n mark-up for the help text from "git -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 ...