git/remote.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: 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: further simplify the logic to assign rejection reason

2013-01-24T22:37:22Z

First compute the reason why this push would fail if done without "--force", and then fail it by assigning that reason when the push was not forced (or if there is no reason to require force, allow it to succeed). Record the fact that the push was forced in the forced_update field only when the push would have failed without the option. The code becomes shorter, less repetitive and easier to read this way, especially given that the set of rejection reasons will be extended in a later patch. Signed-off-by: Junio C Hamano

push: further clean up fields of "struct ref"

2013-01-24T22:37:17Z

The "nonfastforward" and "update" fields are only used while deciding what value to assign to the "status" locally in a single function. Remove them from the "struct ref". The "requires_force" field is not used to decide if the proposed update requires a --force option to succeed, or to record such a decision made elsewhere. It is used by status reporting code that the particular update was "forced". Rename it to "forced_update", and move the code to assign to it around to further clarify how it is used and what it is used for. Signed-off-by: Junio C Hamano

Merge branch 'cr/push-force-tag-update'

2013-01-24T05:16:49Z

Regression fix to stop "git push" complaining "target ref already exists", when it is not the real reason the command rejected the request (e.g. non-fast-forward). * cr/push-force-tag-update: push: fix "refs/tags/ hierarchy cannot be updated without --force"

push: fix "refs/tags/ hierarchy cannot be updated without --force"

2013-01-16T21:03:57Z

When pushing to update a branch with a commit that is not a descendant of the commit at the tip, a wrong message "already exists" was given, instead of the correct "non-fast-forward", if we do not have the object sitting in the destination repository at the tip of the ref we are updating. The primary cause of the bug is that the check in a new helper function is_forwardable() assumed both old and new objects are available and can be checked, which is not always the case. The way the caller uses the result of this function is also wrong. If the helper says "we do not want to let this push go through", the caller unconditionally translates it into "we blocked it because the destination already exists", which is not true at all in this case. Fix this by doing these three things: * Remove unnecessary not_forwardable from "struct ref"; it is only used inside set_ref_status_for_push(); * Make "refs/tags/" the only hierarchy that cannot be replaced without --force; * Remove the misguided attempt to force that everything that updates an existing ref has to be a commit outside "refs/tags/" hierarchy. The policy last one tried to implement may later be resurrected and extended to ensure fast-forwardness (defined as "not losing objects", extending from the traditional "not losing commits from the resulting history") when objects that are not commit are involved (e.g. an annotated tag in hierarchies outside refs/tags), but such a logic belongs to "is this a fast-forward?" check that is done by ref_newer(); is_forwardable(), which is now removed, was not the right place to do so. Signed-off-by: Junio C Hamano

Merge branch 'jc/fetch-ignore-symref'

2013-01-06T07:41:37Z

Avoid false error from an attempt to update local symbolic ref via fetch. * jc/fetch-ignore-symref: fetch: ignore wildcarded refspecs that update local symbolic refs

Merge branch 'cr/push-force-tag-update'

2013-01-06T07:41:34Z

Require "-f" for push to update a tag, even if it is a fast-forward. * cr/push-force-tag-update: push: allow already-exists advice to be disabled push: rename config variable for more general use push: cleanup push rules comment push: clarify rejection of update to non-commit-ish push: require force for annotated tags push: require force for refs under refs/tags/ push: flag updates that require force push: keep track of "update" state separately push: add advice for rejected tag reference push: return reject reasons as a bitset

fetch: ignore wildcarded refspecs that update local symbolic refs

2012-12-11T22:53:32Z

In a repository cloned from somewhere else, you typically have a symbolic ref refs/remotes/origin/HEAD pointing at the 'master' remote-tracking ref that is next to it. When fetching into such a repository with "git fetch --mirror" from another repository that was similarly cloned, the implied wildcard refspec refs/*:refs/* will end up asking to update refs/remotes/origin/HEAD with the object at refs/remotes/origin/HEAD at the remote side, while asking to update refs/remotes/origin/master the same way. Depending on the order the two updates happen, the latter one would find that the value of the ref before it is updated has changed from what the code expects. When the user asks to update the underlying ref via the symbolic ref explicitly without using a wildcard refspec, e.g. "git fetch $there refs/heads/master:refs/remotes/origin/HEAD", we should still let him do so, but when expanding wildcard refs, it will result in a more intuitive outcome if we simply ignore local symbolic refs. As the purpose of the symbolic ref refs/remotes/origin/HEAD is to follow the ref it points at (e.g. refs/remotes/origin/master), its value would change when the underlying ref is updated. Earlier commit da3efdb (receive-pack: detect aliased updates which can occur with symrefs, 2010-04-19) fixed a similar issue for "git push". Signed-off-by: Junio C Hamano

Merge branch 'mm/status-push-pull-advise'

2012-12-03T17:28:43Z

Finishing touch to allow the new advice message squelched with an advice.* configuration variable. * mm/status-push-pull-advise: status: respect advice.statusHints for ahead/behind advice