Junio C Hamano <gitster@xxxxxxxxx> writes: Addendum. > In any case, I thought this series was about users who run "push" > voluntarily stopping themselves from pushing updates to tags that > may happen to fast-forward, so if we were to go with the > configuration route, the suggestion would be more like > > [push] > updateNeedsForce = refs/tags/:refs/frotz/ > > or perhaps > > [remote "origin"] > updateNeedsForce = refs/tags/:refs/frotz/ > > if we want to configure it per-remote, to specify that you would > need to say "--force" to update the refs in the listed hierarchies. > > Then your patch series could become just the matter of declaring > that the value of push.updateNeedsForce, when unspecified, defaults > to "refs/tags/". The above is not a "you should do it this way" suggestion, by the way. I was just explaining what I meant by "it may be a good feature, but may not necessarily be limited to refs/tags" in my earlier message in a different way "... and a possible design that lifts the limitation may go like this". I am *not* convinced that the "refs/tags/ is the only special hierarchy whose contents should not move" is a bad limitation we should avoid, but if it indeed is a bad limitation, the above is one possible way to think about avoiding it. Thanks. -- 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