From 5ece083fc7ffd60d38b9abf7797fbf00decd2bcc Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 21 Jan 2013 20:24:07 -0800 Subject: push: further clean up fields of "struct ref" 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 --- cache.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'cache.h') diff --git a/cache.h b/cache.h index a942bbd59f..12631a17d3 100644 --- a/cache.h +++ b/cache.h @@ -1001,10 +1001,8 @@ struct ref { char *symref; unsigned int force:1, - requires_force:1, + forced_update:1, merge:1, - nonfastforward:1, - update:1, deletion:1; enum { REF_STATUS_NONE = 0, -- cgit v1.2.3 From 75e5c0dc5529aed42122b3a774e6b17383e51b66 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Wed, 23 Jan 2013 13:55:30 -0800 Subject: push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE 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 --- cache.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'cache.h') diff --git a/cache.h b/cache.h index 12631a17d3..377a3df157 100644 --- a/cache.h +++ b/cache.h @@ -1010,6 +1010,8 @@ struct ref { REF_STATUS_REJECT_NONFASTFORWARD, REF_STATUS_REJECT_ALREADY_EXISTS, REF_STATUS_REJECT_NODELETE, + REF_STATUS_REJECT_FETCH_FIRST, + REF_STATUS_REJECT_NEEDS_FORCE, REF_STATUS_UPTODATE, REF_STATUS_REMOTE_REJECT, REF_STATUS_EXPECTING_REPORT -- cgit v1.2.3