resending to list ... On Tue, Nov 13, 2012 at 3:20 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Chris Rorvick <chris@xxxxxxxxxxx> writes: > >> Minor changes since from v2 set. Reposting primarily because I mucked >> up the Cc: list (again) and hoping to route feedback to the appropriate >> audience. >> >> This patch set can be divided into two sets: >> >> 1. Provide useful advice for rejected tag references. >> >> push: return reject reasons via a mask >> push: add advice for rejected tag reference >> >> Recommending a merge to resolve a rejected tag update seems >> nonsensical since the tag does not come along for the ride. These >> patches change the advice for rejected tags to suggest using >> "push -f". > > Below, I take that you mean by "tag reference" everything under > refs/tags/ (not limited to "annotated tag objects", but also > lightweight tags). Yes. > Given that the second point below is to strongly discourage updating > of existing any tag, it might be even better to advise *not* to push > tags in the first place, instead of destructive "push -f", no? That does seem like a better idea. Read the full manual page to figure out how to force the update if that's what you want to do--the advice should not suggest something exceptional. >> 2. Require force when updating tag references, even on a fast-forward. >> >> push: flag updates >> push: flag updates that require force >> push: update remote tags only with force >> >> An email thread initiated by Angelo Borsotti did not come to a >> consensus on how push should behave with regard to tag references. > > I think the original motivation of allowing fast-forward updates to > tags was for people who wanted to have "today's recommended version" > tag that can float from day to day. I tend to think that was a > misguided notion and it is better implemented with a tip of a > branch (iow, I personally am OK with the change to forbid tag > updates altogether, without --force). > >> I think a key point is that you currently cannot be sure your push >> will not clobber a tag (lightweight or not) in the remote. > > "Do not update, only add new" may be a good feature, but at the same > time I have this suspicion that its usefulness may not necessarily > be limited to refs/tags/* hierarchy. > > I dunno. Are you suggesting allowing forwards for just refs/heads/*? I initially went this route based on some feedback in the original thread, but being that specific broke a couple tests in t5516 (i.e., pushing to refs/remotes/origin/master and another into refs/tmp/*.) My initial thought was that I'd broken something and I need to modify the patch, but now I think I should just modify those tests. Branches are restricted to refs/heads/* (if I understand correctly), so allowing fast-forwards when pushing should be limited to this hierarchy, too. Thanks, Chris -- 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