Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.

From: Jeff King <peff@peff.net>
Date: Jun 19, 2008, 13:37 UTC
Message-ID: <20080619133747.GA31209@sigill.intra.peff.net>
In-Reply-To: <1213872715-11182-1-git-send-email-madcoder@debian.org>

On Thu, Jun 19, 2008 at 12:51:55PM +0200, Pierre Habouzit wrote:

Show 5 quoted lines

> It's really painful to have git push error out when it's just that one of
> your tracking branches isn't up to date with respect to a remote branch.
> 
> Let just add a new status: "lagging", always print it to screen when we're
> lagging, but don't exit with a non 0 value, as it really alarms users.

This has been discussed before, and the suggested term was "stale".

Check out:

  http://thread.gmane.org/gmane.comp.version-control.git/73038/focus=73186

which is uncannily identical (the difference is the name, and that I don't show the lagged branches unless -v is given).

Among the issues that were not sorted out last time:

  - should stale branches be shown without -v?

  - calling ref_newer here is inefficient, since we have already called
    it in the other direction. We should probably do the traversal once
    in such a way as to find out which ref is newer (or if it is
    indeterminate).

  - there is a possible danger with "git push -f", in that you force
    both rejected branches as well as stale branches. Junio and I
    discussed the possibility of disallowing "-f" unless the user
    explicitly requested _what_ to push; i.e., --all, --matching,
    --mirror, or a refspec. See:

      http://thread.gmane.org/gmane.comp.version-control.git/74425/focus=74481

I was considering resurrecting my patch after working up that safety valve.

-Peff