On Mon, Oct 29, 2012 at 7:35 AM, Jeff King <p...@peff.net> wrote:
> On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
>> > I would have expected git to at least complain about updating an
>> > annotated tag with another annotated tag. But it actually uses the same
>> > fast-forward rule, just on the pointed-to commits. So a fast-forward
>> > annotated re-tag will throw away the old tag object completely. Which
>> > seems a bit crazy to me.
>> > It seems like a no-brainer to me that annotated tags should not replace
>> > each other without a force, no matter where in the refs hierarchy they
>> > go.
>> > For lightweight tags, I think it's more gray. They are just pointers
>> > into history. Some projects may use them to tag immutable official
>> > versions, but I also see them used as shared bookmarks. Requiring "-f"
>> > may make the latter use more annoying. On the other hand, bookmark tags
>> > tend not to be pushed, or if they are, it is part of a mirror-like
>> > backup which should be forcing all updates anyway.
>> Would that be an endorsement of continuing to build a patch set
>> including the snippet that Kacper posted earlier (1) in response to my
>> comment about not being sure how complicated all of this would be or
> That patch just blocks non-forced updates to refs/tags/. I think a saner
> start would be to disallow updating non-commit objects without a force.
> We already do so for blobs and trees because they are not (and cannot
> be) fast forwards. The fact that annotated tags are checked for
> fast-forward seems to me to be a case of "it happens to work that way"
> and not anything planned. Since such a push drops the reference to the
> old version of the tag, it should probably require a force.
> Then on top of that we can talk about what lightweight tags should do.
> I'm not sure. Following the regular fast-forward rules makes some sense
> to me, because you are never losing objects. But there may be
> complications with updating tags in general because of fetch's rules,
> and we would be better off preventing people from accidentally doing so.
> I think a careful review of fetch's tag rules would be in order before
> making any decision there.
Thanks, I had the sinking suspicion that this was going to be more complicated.
"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