Dummies like me do not understand readily that "remote object abcdef...
does not exist on local" means: "Hey, you did not pull this, did you?".
So, add "(pull first?)" to that message.
Signed-off-by: Johannes Schindelin <redacted>
---
Wow, my commit messages get longer, while the patches get shorter.
Odd.
send-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
af2d86726fe961043d0c69c4fb727689a5903b63
diff --git a/send-pack.c b/send-pack.c
index 5bc2f01..643662a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -233,7 +233,7 @@ static int send_pack(int in, int out, in
!ref->force) {
if (!has_sha1_file(ref->old_sha1)) {
error("remote '%s' object %s does not "
- "exist on local",
+ "exist on local (pull first?)",
ref->name, sha1_to_hex(ref->old_sha1));
ret = -2;
continue;--
0.99.9.GIT
Johannes Schindelin [off-list ref] writes:
Dummies like me do not understand readily that "remote object abcdef...
does not exist on local" means: "Hey, you did not pull this, did you?".
So, add "(pull first?)" to that message.
I am ambivalent about this one. It is a special case of "remote
is not a strict subset of local" situation, so we might be
better if we just said the same as the other error message and
be done with it. On the other hand, the code does know the
difference of the two situations at this point, and it could be
argued that giving the same error is losing information.
Earlier I once rewound the "master" branch head by one commit
too much by mistake. The next push to the public server would
have given me a different error message, depending on whether I
pruned my private repository or not in between. For example,
after this sequence:
$ git commit -m 'initial'
$ git commit -m 'next'
$ git push remote master
$ git reset --hard HEAD^
$ git commit -m 'third but second'
If you do not prune at this point, then the remote commit "next"
still exists in the local repository (but not reachable). Then
$ git push remote master
would not say "pull first?". But if you prune local repository
before pushing, it would now say "pull first?".
In a sense, both are "pull first?" situation, and it probably is
more confusing to give different messages to the user in these
two cases. From the end-user point of view they are the same
"remote is not strict subset.".
Junio C Hamano wrote:
In a sense, both are "pull first?" situation, and it probably is
more confusing to give different messages to the user in these
two cases. From the end-user point of view they are the same
"remote is not strict subset.".
In non-git'ish, does this mean "you're not up to date, so pull before
pushing" ? If so, why not say so? I'm sure it could prevent a fair few
problems for users (not least those new to scm's).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Andreas Ericsson [off-list ref] writes:
Junio C Hamano wrote:
quoted
In a sense, both are "pull first?" situation, and it probably is
more confusing to give different messages to the user in these
two cases. From the end-user point of view they are the same
"remote is not strict subset.".
In non-git'ish, does this mean "you're not up to date, so pull before
pushing" ? If so, why not say so? I'm sure it could prevent a fair few
problems for users (not least those new to scm's).
Perhaps. I was suggesting to say that in *both* places, not
just one.