(oops, now my email was rejected) On Wed, Oct 31, 2012 at 12:55 AM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > Hi, > > (again because the mailing list rejected it) (Gmal switched interface > and HTML is the default) > > On Wed, Oct 31, 2012 at 6:37 AM, Chris Rorvick <ch...@rorvick.com> wrote: >> >> References are allowed to update from one commit-ish to another if the >> former is a ancestor of the latter. This behavior is oriented to >> branches which are expected to move with commits. Tag references are >> expected to be static in a repository, though, thus an update to a >> tag (lightweight and annotated) should be rejected unless the update is >> forced. >> >> To enable this functionality, the following checks have been added to >> set_ref_status_for_push() for updating refs (i.e, not new or deletion) >> to restrict fast-forwarding in pushes: >> >> 1) The old and new references must be commits. If this fails, >> it is not a valid update for a branch. >> >> 2) The reference name cannot start with "refs/tags/". This >> catches lightweight tags which (usually) point to commits >> and therefore would not be caught by (1). >> >> If either of these checks fails, then it is flagged (by default) with a >> status indicating the update is being rejected due to the reference >> already existing in the remote. This can be overridden by passing >> --force to git push. >> >> The new status has the added benefit of being able to provide accurate >> feedback as to why the ref update failed and what can be done. >> Currently all ref update rejections are assumed to be for branches. > > Makes sense to me. I've believe I've been hit by this a couple of > times when tags were updated, and a colleague did 'git push' and they > went all back, or something like that. To handle that case properly > probably more changes are needed, but this is a change in the right > direction. > >> +test_expect_success 'push tag requires --force to update remote tag' ' >> + mk_test heads/master && >> + mk_child child1 && >> + mk_child child2 && >> + ( >> + cd child1 && >> + git tag lw_tag && >> + git tag -a -m "message 1" ann_tag && >> + git push ../child2 lw_tag && >> + git push ../child2 ann_tag && >> + >file1 && >> + git add file1 && >> + git commit -m "file1" && >> + git tag -f lw_tag && >> + git tag -f -a -m "message 2" ann_tag && >> + ! git push ../child2 lw_tag && > > You probably should use test_must_fail.
Thanks, will fix. > I don't see anything wrong with the patch, but I wonder if it might be > possible to split it to ease the review. I initially thought I'd split it into two: 1) to improve the feedback and 2) to change the behavior. But (1) was shaping up to be similar in size to the sum so I scrapped that idea. I will see what I can do. Thanks, Chris -- 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
