On Mon, Sep 5, 2011 at 13:47, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Sep 05, 2011 at 11:15:26AM -0700, Shawn O. Pearce wrote: >> Maybe instead of getting a project policy from the server, we observe >> the server's behavior over time from the client's reflog. > > Hmm. That would probably work most of the time in practice. But it seems > like it would be quite confusing when the heuristic is wrong (e.g., > Junio rewinds next once every few months, and other than that, it always > fast forwards). On the other hand, if the failure mode of the heuristic > is only a slightly bigger warning, then it's not that big a deal. Right. Its probably a bigger failure not to warn than to warn here too. >> The main reason to alert the user that a branch rewound is to give >> them a chance to correct their client if they need to. If a branch >> normally doesn't rewind (e.g. next) but then suddenly does (e.g. >> release cycle), but I haven't used this client in 3 weeks, its nice to >> give me more of a "HEY STUPID FIX YOUR TOPICS" warning than just the >> little quiet "force update" we give. > > Sure. I'm totally open to the idea of making the non-fast-forward > warning more obvious. Suggestions for wording (though I am tempted by > "HEY STUPID" above ;) )? I'm not suggesting all non-fast-forward should issue a bigger warning. pu updates daily with a non-fast-forward. That isn't useful. But if the local reflog hints that this reference almost never does a non-fast-forward, and then it does, that should be a big warning. -- Shawn. -- 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