From: Jeff King Date: Thu, 19 Jun 2008 13:37:48 GMT Subject: Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors. 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: > 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