From: Junio C Hamano Date: Wed, 07 Sep 2011 21:53:32 GMT Subject: Re: [RFC/PATCH] fetch: bigger forced-update warnings Message-ID: <7vty8o10kj.fsf@alter.siamese.dyndns.org> In-Reply-To: <20110907212042.GG13364@sigill.intra.peff.net> Jeff King 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 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.