On Mon, Sep 5, 2011 at 13:47, Jeff King [off-list ref] wrote:
On Mon, Sep 05, 2011 at 11:15:26AM -0700, Shawn O. Pearce wrote:
quoted
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.
quoted
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.