Re: [PATCH v3 0/5] push: update remote tags only with force

From: Chris Rorvick <chris@rorvick.com>
Date: Nov 14, 2012, 06:29 UTC
Message-ID: <CAEUsAPZtF-L5J_g1L5d44BKveoAnJ81PatX94fFS4FM=iW33KA@mail.gmail.com>
In-Reply-To: <CAEUsAPYvrR6WsVWCvwoEWA21gzL6Sib0sTyx-c_2tH=8ni69yQ@mail.gmail.com>

resending to list ...

On Tue, Nov 13, 2012 at 3:20 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

> Chris Rorvick <chris@rorvick.com> 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.

Show 24 quoted lines

>>   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