Jeff King <peff@xxxxxxxx> writes:
> 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/
> 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@xxxxxxxx>
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.
> +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.
--
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