Hi Junio, > 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.
What other hierarchy besides branches and tags is there? Do you have in mind some other that should not move? -Angelo On 15 November 2012 01:09, Junio C Hamano <gits...@pobox.com> wrote: > Junio C Hamano <gits...@pobox.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
