[rfd] auto-following tags upon "git push"?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[rfd] auto-following tags upon "git push"?

Junio C Hamano
It has been a very conscious design decision that "git push" does not push
tags without being told, as opposed to "git fetch" that can fetch tags
that point at commits that are being transferred.

The rationale is quite obvious, once you think about it. When fetching,
you are interacting with a remote repository somebody has published, which
means two important things: (1) the set of tags that exist there are all
the publisher wanted people to see, and (2) not only you but other people
will also see the same tags. In other words, tags in repositories you
fetch from are designed to be public and shared. It will facilitate
communication between developers if it is easy for everybody to fetch
these same tags.

When pushing, you are pushing from your working repository, which most of
the time is not public, and tags in that repository is not designed to be
public. You can use your own local tags to mark your progress, so it does
not make sense to blindly push all tags in your repository to the
repository you are pushing to publish your changes, whose tags are by
definition public.

        Side note: the same logic applies to pushing branches. The
        branches in the remote you fetch from are public, the ones in your
        repository are mixture of branches for your private work and
        branches for public consumption.

So the recommended workflow for publishers has always been:

 - work on private topic branches that do not have corresponding branches
   at the publishing repository to cook your work-in-progress;

 - integrate them when they are done to branches that do have
   corresponding branches at the publishing repository;

 - "git push" without any extra configuration will push "matching"
   branches, so that your private topic branches will stay private, and
   the integration branches used to communicate with everybody else will
   be pushed;

 - You can use a private tag to mark your point if you want to, and
   you can tag a release on a branch that is shared with public.

 - A new branch, or a new tag to be made public needs to be pushed
   explicitly. Requiring an explicit push, instead of blindly pushing
   everything, avoids contaminating the ref namespace of the public
   repository with your private topic branches and private tags by
   accident.

But we could do better.

Tags are designed to promote sharing of common reference points; the goal
is to ensure that within the scope of a project, when somebody says v1.0
is buggy, everybody else knows exactly which version v1.0 refers to (this
is the primary reason why we do not use separate-remote layout for tags).

Which also means that there is a social convention among everybody in the
project how public tags are named. Using a tag v2.4.3 to mark your private
progress point, when the project uses tags that match "v*.*.*" to mark
public releases, is not something any sane person would do.

So, while we still should _never_ automatically push any tag that points
at a commit that is being pushed out (i.e. inverse of "fetch" that auto
follows tags), if the user or the project can give a clear enough hint to
git which tags are for public consumption, we should at least be able to
push tags that are for public consumption and do point at commits that are
being pushed out.

This is just me thinking out loud, but a typical end-user transcript may
look something like this:

   Tell git that v*.* and v*.*.* are release tags (one-time set-up).
   $ git config --unset-all push.autotag
   $ git config --add push.autotag 'v*.*'
   $ git config --add push.autotag 'v*.*.*'

   Usual development process.
   $ git checkout master
   $ work work work

   Not very happy as the result is a mess, but it seems to work Ok.
   $ git tag wip

   Try it again with the wisdom gained from the previous attempt.
   $ rework rework rework

   How much improvement did we make? Hmm, looks good.
   $ git diff wip

   Use that for the release.
   $ git tag v1.2.0

   Push it out, with the usual matching (or "upstream") semantics plus
   the new auto-follow tags feature. Note that "wip" tag will not be sent.
   $ git push
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: [rfd] auto-following tags upon "git push"?

Shawn Pearce
On Tue, Jun 7, 2011 at 09:33, Junio C Hamano <[hidden email]> wrote:
>
> Which also means that there is a social convention among everybody in the
> project how public tags are named. Using a tag v2.4.3 to mark your private
> progress point, when the project uses tags that match "v*.*.*" to mark
> public releases, is not something any sane person would do.
...
> This is just me thinking out loud, but a typical end-user transcript may
> look something like this:
>
>   Tell git that v*.* and v*.*.* are release tags (one-time set-up).
>   $ git config --unset-all push.autotag
>   $ git config --add push.autotag 'v*.*'
>   $ git config --add push.autotag 'v*.*.*'
...
>   $ git tag v1.2.0
>
>   Push it out, with the usual matching (or "upstream") semantics plus
>   the new auto-follow tags feature. Note that "wip" tag will not be sent.
>   $ git push

Questions:

Does push.autotag apply to all remotes? I'm debating with myself if I
really want a tag I have created locally immediately pushed to a
backup repository. Just because I have tagged something on my primary
work repository, doesn't mean I want that public yet. I may have
temporarily tagged something, started building a release, then run a
"git push backup" to send my branch tips to a private backup
repository and jumped on the transit system to head home.
Automatically pushing my newly created tag to my backup may be useful,
but if I later move that tag before I make it public pushes to my
backup might start failing. If my backup remote doesn't have a
remote.backup.push refspec that includes refs/tags/* namespace, should
push.autotag really send there?

Does push.autotag trigger if I specify push refspecs on the command
line? It probably should, as the user might have specifically
configured certain refs (maint, master, next, pu, todo) to be
published. Unless the user is pushing to Gerrit Code Review's magical
"refs/for/*" destination namespace... in which case that tag might
still only be a tentative tag and isn't really part of the project
history yet.


In general I agree with this idea. Its similar to the tag following we
are doing on fetch/clone, and its similar to the tag visibility that
Gerrit Code Review does with per-branch access controls.

Unfortunately you need to configure the patterns up front. This is
advanced user space. But the feature is most likely to help the new
project maintainer more than an existing user.

--
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: [rfd] auto-following tags upon "git push"?

Jeff King
In reply to this post by Junio C Hamano
On Tue, Jun 07, 2011 at 09:33:35AM -0700, Junio C Hamano wrote:

> So, while we still should _never_ automatically push any tag that points
> at a commit that is being pushed out (i.e. inverse of "fetch" that auto
> follows tags), if the user or the project can give a clear enough hint to
> git which tags are for public consumption, we should at least be able to
> push tags that are for public consumption and do point at commits that are
> being pushed out.
>
> This is just me thinking out loud, but a typical end-user transcript may
> look something like this:
>
>    Tell git that v*.* and v*.*.* are release tags (one-time set-up).
>    $ git config --unset-all push.autotag
>    $ git config --add push.autotag 'v*.*'
>    $ git config --add push.autotag 'v*.*.*'

Hmm. Is it a clear enough hint when the user uses an actual tag object
to make a signed or annotated tag? At least for me, private throw-away
tags tend to just be refs/tags/foo pointing to a commit, and real,
for-public-consumption tags at least get an annotation, if not a
signature.

I seem to recall we make a similar distinction somewhere else in the
code, but I can't remember offhand where. Maybe it was just a proposal
that never made it anywhere.

Anyway, the problem would be somebody who does something like:

  $ git tag -m "here is a description of how this wip is going" foo-wip

which violates the assumption above. I have no idea how common that is
(I tend to write such descriptions into a WIP commit message, and if I
really want to, tag the resulting commit directly).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: [rfd] auto-following tags upon "git push"?

Junio C Hamano
Jeff King <[hidden email]> writes:

> Hmm. Is it a clear enough hint when the user uses an actual tag object
> to make a signed or annotated tag? At least for me, private throw-away
> tags tend to just be refs/tags/foo pointing to a commit, and real,
> for-public-consumption tags at least get an annotation, if not a
> signature.
>
> I seem to recall we make a similar distinction somewhere else in the
> code, but I can't remember offhand where. Maybe it was just a proposal
> that never made it anywhere.

You are thinking about "describe", I think, and the analogy holds
true. The tag annotation vs lightweight tag is a good hint I forgot to
take into account.

> Anyway, the problem would be somebody who does something like:
>
>   $ git tag -m "here is a description of how this wip is going" foo-wip
>
> which violates the assumption above.

True, I think I did that sometimes.

I personally do not use "private tags" that much anymore; I make liberal
use of private branches for that kind of work instead, as it is more
flexible (I can check it out, build on it, rebase -i, and generally whip
it around in any other way).

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: [rfd] auto-following tags upon "git push"?

sdaoden
In reply to this post by Junio C Hamano
If there would be a free bit somewhere in a tag object (or so):

    $ git tag --autopush -ma "This will be pushed along it's commit" T1

This i would understand at a glance!
And it is both, explicit on the one and automatic on the other
hand.  I.e.: work, work, work - commit & tag, hours pass until
internet access and then

    $ if-up-and-push-it-all-and-if-down.sh

.. and that would only do 'cd repo && git push'.
But having a short look into tag.c does not give much hope on that.
Maybe a new file .git/AUTOPUSH to which all SHA-1 to be
pushed automatically are simply appended.

@ Junio C Hamano <[hidden email]> wrote:
>    Tell git that v*.* and v*.*.* are release tags (one-time set-up).
>    $ git config --unset-all push.autotag
>    $ git config --add push.autotag 'v*.*'
>    $ git config --add push.autotag 'v*.*.*'

I will blow that one, one of these days.

@ Jeff King <[hidden email]> wrote:

> Hmm. Is it a clear enough hint when the user uses an actual tag
> object to make a signed or annotated tag? At least for me,
> private throw-away tags tend to just be refs/tags/foo pointing
> to a commit, and real, for-public-consumption tags at least get
> an annotation, if not a signature.
> [.] Anyway, the problem would be somebody who does something like:
>
>  $ git tag -m "here is a description of how this wip is going" foo-wip
>
> which violates the assumption above. I have no idea how common that is

I did understand that -m/-F required storage and thus force
creation of a tag object.  But hey - it's a bit odd, isn't it?
(Thinking about it some more it's very convenient that the
possibility exists.  But it will require more than one glance.
You know - that's ok for me, given all those features which will
make life easier once they're discovered and understood.)
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html