Re: git push tags
- From
Kacper Kornet <draenog@pld-linux.org>
- Date
- Oct 29, 2012, 17:23 UTC
- Message-ID
- <20121029172330.GC8359@camk.edu.pl>
- In-Reply-To
- <20121029113500.GA15597@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 07:35:00AM -0400, Jeff King wrote:
> On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
Show 5 quoted lines
> > > 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.
Show 6 quoted lines
> > > 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 > > not?
Show 7 quoted lines
> 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.
I'm not sure. Looking at 37fde87 ("Fix send-pack for non-commitish tags.") I have an impression that Junio allowed for fast-forward pushes of annotated tags on purpose.
Show 7 quoted lines
> 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.
The problem with the current behaviour is, that one can never be 100% sure that his push will not overwrite someone else tag.
-- Kacper