Re: [PATCH v2 0/4] push --follow-tags

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2013, 15:55 UTC
Message-ID: <7v8v60seuc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130306084105.GB2018@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote:
>
>> The primary change since the last round is that it pushes out only
>> annotated tags that are missing from the other side.
>
> Like you, I have mixed feelings on treating annotated tags separately. I
> don't feel like the previous discussion actually came to a conclusion.
>
> I kind of lean towards the "if we are pushing A..B to a ref,...

I rejected that approach when I started writing the initial round of this topic, primarily because A (i.e. dst_ref->old_sha1) may not necessarily be what the current pusher pushed out during his last push.

The criteria for the tip of a branch to be good enough to be pushed out and the criteria for a commit to be good enough to be tagged are different. You may know that a commit together with the history behind it is solid and may be sure that you will not have to rewind beyond that commit---that is when you _can_ push out (you do not have to, and I usually don't, so this is not a problem for me personally).

But at that point in time, you may still not know if the commit and the history behind it is the good point to be tagged for a release, or you would still need some other commits on top to polish other areas for the tagged release is complete.

As I made a habit of not pushing anything out if I am planning to tag in a near future (and my tagged commits are ones designed to be tagged, not just an ordinary commit that happens to be tagged), it is not a problem for me, but it would be for "centralized workflow" people, where there is more pressure to publish a commit as early as possible. Once you know the commit is good enough so that you do not anticipate that it will need to be rewound, you want to push it out so that you can unblock others who want to build on it. It is plausible to see:

    (1) The pumpking pushes 'master' after being satisfied the
        correctness of the history that leads to it.  The pumpking
        hasn't decided if the commit is to be tagged, or needs some
        other commits on top, for the next release.  But he prefers
        to push the current state out so that he can unblock other
        people.

    (2) Another committer pulls and pushes with his changes.

    (3) The pumpking tags what he pushed out with (1), attempts a
        push, fails the ff check, pulls (2) and then pushes the
        result out with "push --follow-tags".