Re: [RFC/PATCH] fetch: bigger forced-update warnings

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 7, 2011, 21:53 UTC
Message-ID: <7vty8o10kj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110907212042.GG13364@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> Subject: fetch: bigger forced-update warnings
>
> The default fetch refspec allows forced-updates. We already
> print "forced update" in the status table, but it's easy to
> miss. Let's make the warning a little more prominent.
>
> Some branches are expected to rewind, so the prominent
> warning would be annoying. However, git doesn't know what
> the expectation is for a particular branch. We can have it
> guess by peeking at the lost couple of reflog entries. If we

s/lost/last/

Show 7 quoted lines

> see all fast forwards, then a new forced-update is probably
> noteworthy. If we see something that force-updates all the
> time, it's probably boring and not worth displaying the big
> warning (we keep the status table "forced update" note, of
> course).
>
> Signed-off-by: Jeff King <peff@peff.net>

This is slightly offtopic, but I have been wondering if this approach do the right thing for "git pull". Wouldn't the underlying "git fetch" give a warning, and then the calling "git pull" go ahead and make a merge, scrolling the warning away with the merge/update summary diffstat? That would be a larger change if "git pull" needs to stash away the warning message, do its thing and then spit out the warning later.

Show 8 quoted lines

> +static int forced_update_is_uncommon(const char *ref)
> +{
> +	struct update_counts uc;
> +	memset(&uc, 0, sizeof(&uc));
> +	if (for_each_recent_reflog_ent(ref, count_updates, 4096, &uc) < 0)
> +		for_each_reflog_ent(ref, count_updates, &uc);
> +	return uc.fastforward && uc.forced <= 1; /* 1 for the one we just did */
> +}

Looks sensible.