On Sat, Feb 09, 2008 at 11:27:51AM +1300, Martin Langhoff wrote:
> Exactly. And we could show a nicer message - rejected is too strong a
> word ;-)
Like
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 454ad8f..3979918 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -315,7 +315,7 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count)
ref->peer_ref, NULL);
break;
case REF_STATUS_REJECT_NONFASTFORWARD:
- print_ref_status('!', "[rejected]", ref, ref->peer_ref,
+ print_ref_status('!', "[kindly refused]", ref, ref->peer_ref,
"non-fast forward");
break;
case REF_STATUS_REMOTE_REJECT:
?
> The local side has the remote refs if the client has fetched recently,
> so it might be able to tell in some cases. Not with authority (things
> may have changed on the server side...) but the client might be able
> to say something less alarming.
This is actually not that hard to do in the case that we can. Patch will
follow in a second, though I am not sure it is a good idea (because it
silently ignores pushing rewinds).
> > Another way to "solve" this issue, of course, is to use the remote layout.
> > I did the switchover myself some time ago; it was hard at first, since I
> > was so used to just check out the branches I just fetched. But in the
> > long run the distinction between local and tracking branches made life
> > much easier for me.
>
> What do you mean with "the remote layout"? I am using
> "remotes"+tracking branches as far as I can tell...
I think he means something like "if I have 'next' and 'origin/next',
then I should check whether 'next' is a subset of 'origin/next'" and
just say "nothing to send." But that suffers from the same "silently
ignoring rewinds" as above. You could ignore the push if you have
next exactly equal to origin/next, but that implies that you haven't done
any fetching (which is unlikely in the scenario you described).
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
