Re: [PATCH 1/3] push: indicate partialness of error message

From: Jeff King <peff@peff.net>
Date: Feb 19, 2008, 21:54 UTC
Message-ID: <20080219215441.GA7778@coredump.intra.peff.net>
In-Reply-To: <7vablwiqa7.fsf@gitster.siamese.dyndns.org>

On Tue, Feb 19, 2008 at 01:34:40PM -0800, Junio C Hamano wrote:

Show 5 quoted lines

> Distinguishing between [rejected] and [stale] would belong in
> 1.5.5 if it is really needed.  Together with the "git checkout
> notices forks" enhancement on Daniel's git-checkout rewritten in
> C, I think it would solve the issue in the "push [rejected]
> question".

I am still a little uncomfortable with the rejected/stale distinction, because the semantics aren't clear.

Let's say we figure out which is which in send-pack. Do we:

  - simply change the "rejected" text to "stale, and leave as-is? I
    think that is safe, but I also think it isn't a significant
    improvement for workflows that leave lots of stale branches around
    (they clutter the push output).
  - omit stale listings when -v is not given?
    - this is dangerous with the patch I posted, because "git push; #
      oops, I forgot I amended; git push -f" will push stale branches
      that weren't even mentioned in the first case.
    - instead, should we require some extra magic to force stale
      branches to be pushed? Forcing such a push is almost never a good
      idea, whereas forked branches are not too uncommon.
    - instead, should we disallow "-f" without an explicit refspec (or
      --all, or --mirror, etc) I can't think of a workflow where you
      want to force _many_ branches at once, except the special case of
      mirroring.
    - we could also combine the two: don't respect -f on stale pushes,
      but do respect pushing "+stale"

Thoughts?

-Peff