On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti
---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
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
> 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.
"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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html