On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti <angelo.borsotti@xxxxxxxxx> wrote: ---At 13:19 on Oct 25, 2012, Drew Northup wrote: [added for clarity] >>Tags have many uses. Some of those uses are harmed when tags change > and some aren't. That's a philosophical argument > > I agree, but in this case the computer does not provide any means to > implement the same strategy on tags as it does instead on local > repositories. Why I must force a change on a tag in the local > repository and instead I can change it without any forcing in a remote > one? Changing the tag in the local repository is a tag modification operation. Pushing that change to a remote repository DOES NOT execute "git tag...." in the remote. Plain and simple the two are different operations. > Are remote repositories less protected than the local ones? I > think that to be consistent, the same strategy should be used on all > repositories, i.e. rejecting changes on tags by default, unless they > are forced. So here we come to the core argument. Is sounds to me like you want changes to remote tags to work differently from push updates to ALL other references. The required change, if I'm not mistaken, would be for tags to not permit fast-forward updates while all other references would be pushed normally. From my brief and un-enlightened look at the push code I can't see that being as easy as it sounds. In any case, I think your complaint stems from thinking that "git tag" is the operation being performed on the remote when in fact it is not. Given the mayhem that changing this may involve I'm not going to claim it to be a good idea. -- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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