Jabber, question on push,pull and --tags, and no help but jabber

Jabber, question on push,pull and --tags, and no help but jabber

[Steffen Daode Nurpmeso]

Hello GIT,
    first paragraph is reserved for praising your existence.
    'Used cvs(1) for long years in small team projects with local
    private repos and never felt the need for anything else.  2011
    is different.  I first tried you but failed resoundingly.  Due
    to vim(1) and mutt(1) i discovered hg(1) and i still love it's
    simple usage.  'Talking about the front-end anyway.  It's huge
    memory consumption and slow performance forbids it's usage on
    our old PCs (e.g. Cyrix 166+) though.  So i came back and
    found you still receptive!  And the more i work, the less
    i hurt, the greater the knowledge, the smoother the
    interaction.  Are you the final word on RC in the end?

I stumbled over one thing i don't understand, because it seems
illogical: why do i need to use --tags to force pushing of tags?
Because there is even a config option for the latter, i suspect
this is because of intention.  It would be nice to get some
information on the background of that, like a link to yet existing
documentation.  Anyway i was a bit astonished to look at some
heavily scripted page of my free private repo webhoster :-) and
don't see any tags, even though i've pushed multiple times and
v0.0.0 was created directly after the first commit.  I would *not*
have detected that otherwise ...
(Yes i know it's somewhat implied by 'git help push'..--tags.
But i'm blonde.)

Some more i'll pack into this so that it's gone with the wind:

- Due to my weak GPRS or noisy HDSPA radio connection here in the
  pampa :) i hope for continuable network actions - failing after
  98% is a costly pain.  So it was a real joy to read somewhere
  that a GSOC project will address this issue!!
- OpenSSL support for signing.  I don't use PGP/GPG.  But i use
  HTTPS, POPS, SSH etc., so i'll have an OpenSSL/OpenSSH
  environment here on my box ready to use.

Thanks for GIT!
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Michael J Gruber]

Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:
> Hello GIT,
>     first paragraph is reserved for praising your existence.
>     'Used cvs(1) for long years in small team projects with local
>     private repos and never felt the need for anything else.  2011
>     is different.  I first tried you but failed resoundingly.  Due
>     to vim(1) and mutt(1) i discovered hg(1) and i still love it's
>     simple usage.  'Talking about the front-end anyway.  It's huge
>     memory consumption and slow performance forbids it's usage on
>     our old PCs (e.g. Cyrix 166+) though.  So i came back and
>     found you still receptive!  And the more i work, the less
>     i hurt, the greater the knowledge, the smoother the
>     interaction.  Are you the final word on RC in the end?
> 
> I stumbled over one thing i don't understand, because it seems
> illogical: why do i need to use --tags to force pushing of tags?
> Because there is even a config option for the latter, i suspect
> this is because of intention.  It would be nice to get some
> information on the background of that, like a link to yet existing
> documentation.  Anyway i was a bit astonished to look at some

Tags may contain private information. Say you pull some changes from
your head of group, find a strange commit you want to look at later and
tag it with "what-is-this-crap"...

More seriously, tags are not part of the "remotes layout", so when you
push them and others pull them they overwrite their tags if there's a
name clash.

> heavily scripted page of my free private repo webhoster :-) and
> don't see any tags, even though i've pushed multiple times and
> v0.0.0 was created directly after the first commit.  I would *not*
> have detected that otherwise ...
> (Yes i know it's somewhat implied by 'git help push'..--tags.
> But i'm blonde.)
> 
> Some more i'll pack into this so that it's gone with the wind:
> 
> - Due to my weak GPRS or noisy HDSPA radio connection here in the
>   pampa :) i hope for continuable network actions - failing after
>   98% is a costly pain.  So it was a real joy to read somewhere
>   that a GSOC project will address this issue!!
> - OpenSSL support for signing.  I don't use PGP/GPG.  But i use
>   HTTPS, POPS, SSH etc., so i'll have an OpenSSL/OpenSSH
>   environment here on my box ready to use.

"git tag" and "git verify-tag" call out to "gpg". That could be easily
adapted to call out to "openssl smime", or put your S/MIME signatures in
a note.

Cheers
Michael

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Felipe Contreras]

On Mon, Jun 6, 2011 at 5:31 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:
>> Hello GIT,
>>     first paragraph is reserved for praising your existence.
>>     'Used cvs(1) for long years in small team projects with local
>>     private repos and never felt the need for anything else.  2011
>>     is different.  I first tried you but failed resoundingly.  Due
>>     to vim(1) and mutt(1) i discovered hg(1) and i still love it's
>>     simple usage.  'Talking about the front-end anyway.  It's huge
>>     memory consumption and slow performance forbids it's usage on
>>     our old PCs (e.g. Cyrix 166+) though.  So i came back and
>>     found you still receptive!  And the more i work, the less
>>     i hurt, the greater the knowledge, the smoother the
>>     interaction.  Are you the final word on RC in the end?
>>
>> I stumbled over one thing i don't understand, because it seems
>> illogical: why do i need to use --tags to force pushing of tags?
>> Because there is even a config option for the latter, i suspect
>> this is because of intention.  It would be nice to get some
>> information on the background of that, like a link to yet existing
>> documentation.  Anyway i was a bit astonished to look at some
>
> Tags may contain private information. Say you pull some changes from
> your head of group, find a strange commit you want to look at later and
> tag it with "what-is-this-crap"...
>
> More seriously, tags are not part of the "remotes layout", so when you
> push them and others pull them they overwrite their tags if there's a
> name clash.

Until tag namespaces are merged.

-- 
Felipe Contreras

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Steffen Daode Nurpmeso]

@ Michael J Gruber <git@drmicha.warpmail.net> wrote (2011-06-06 16:31+0200):
> "git tag" and "git verify-tag" call out to "gpg". That could be easily
> adapted to call out to "openssl smime", or put your S/MIME signatures in
> a note.
> 
> Cheers
> Michael

Hum.  It will indeed be possible to place a wrapper script 'gpg'
in the path on my box (and catch '--verify' - or sign otherwise).

But in the meanwhile i've found out that git(1) is heavily
developed, stale .git_vtag_ files of an 1.7.3? version are no
longer produced by 'git version 1.7.6.rc0' to which i've updated
after i've seen those.  So maybe there is hope that the hardcoded
gpg invocation will be replaced by configuration options in the
future, too?

I still don't understand the design with pull and --tags.
Because, if i do 'git log' it'll display the relationship as in

    commit fd040fb[...] (tag: refs/tags/v0.3.0, refs/remotes/origin/master)

So i'll push this commit object as part of pushing a branch, and
the tag refers to *it*.  I don't want to be impertinent though,
and it's better that explicit way than implicitely pushing some
distressing stuff.  Still i would have appreciated a note in the
docu, because it took a look at the mentioned webspace to realize
the situation.  I'll append a short diff to be able to provide
something useful.  (No attachments allowed here i guess.)

I'll try to be less tiny from the start the next time.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

--
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 88acfcd..da4a71a 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -69,7 +69,7 @@ nor in any Push line of the corresponding remotes file---see below).
 
 --all::
 	Instead of naming each ref to push, specifies that all
-	refs under `refs/heads/` be pushed.
+	refs under `refs/heads/` be pushed explicitely.
 
 --mirror::
 	Instead of naming each ref to push, specifies that all
@@ -98,7 +98,7 @@ nor in any Push line of the corresponding remotes file---see below).
 --tags::
 	All refs under `refs/tags` are pushed, in
 	addition to refspecs explicitly listed on the command
-	line.
+	line.  Note that tags are not pushed automatically.
 
 --receive-pack=<git-receive-pack>::
 --exec=<git-receive-pack>::

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Michael J Gruber]

Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 23:46:
> @ Michael J Gruber <git@drmicha.warpmail.net> wrote (2011-06-06 16:31+0200):
>> "git tag" and "git verify-tag" call out to "gpg". That could be easily
>> adapted to call out to "openssl smime", or put your S/MIME signatures in
>> a note.
>>
>> Cheers
>> Michael
> 
> Hum.  It will indeed be possible to place a wrapper script 'gpg'
> in the path on my box (and catch '--verify' - or sign otherwise).

I didn't mean to shove a disguised openssl-smime into the path, I meant
that that there is little to change in code because git calls out to gpg
rather than doing it itself.

> But in the meanwhile i've found out that git(1) is heavily
> developed, stale .git_vtag_ files of an 1.7.3? version are no
> longer produced by 'git version 1.7.6.rc0' to which i've updated
> after i've seen those.  So maybe there is hope that the hardcoded
> gpg invocation will be replaced by configuration options in the
> future, too?

I don't know if it needs to be configurable. That may open a can of worms.

> I still don't understand the design with pull and --tags.
> Because, if i do 'git log' it'll display the relationship as in
> 
>     commit fd040fb[...] (tag: refs/tags/v0.3.0, refs/remotes/origin/master)

git log does that only when you ask it to decorate the commits.
"decoration" means looking up all refs and checking whether one of them
references that commit. Neither the tag (object) nor the ref names (tag
name, branch name) are part of the commit, so:

> So i'll push this commit object as part of pushing a branch, and
> the tag refers to *it*.  I don't want to be impertinent though,

The tag name is not pushed, but the commit object is and has the same
sha1 on "both sides", which is why the remote branch name shows up as a
decoration.

> and it's better that explicit way than implicitely pushing some
> distressing stuff.  Still i would have appreciated a note in the
> docu, because it took a look at the mentioned webspace to realize
> the situation.  I'll append a short diff to be able to provide
> something useful.  (No attachments allowed here i guess.)
> 
> I'll try to be less tiny from the start the next time.
> --
> Ciao, Steffen
> sdaoden(*)(gmail.com)
> () ascii ribbon campaign - against html e-mail
> /\ www.asciiribbon.org - against proprietary attachments
> 
> --
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 88acfcd..da4a71a 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -69,7 +69,7 @@ nor in any Push line of the corresponding remotes file---see below).
>  
>  --all::
>  	Instead of naming each ref to push, specifies that all
> -	refs under `refs/heads/` be pushed.
> +	refs under `refs/heads/` be pushed explicitely.

I don't mind but I don't think it adds clarity.

>  
>  --mirror::
>  	Instead of naming each ref to push, specifies that all
> @@ -98,7 +98,7 @@ nor in any Push line of the corresponding remotes file---see below).
>  --tags::
>  	All refs under `refs/tags` are pushed, in
>  	addition to refspecs explicitly listed on the command
> -	line.
> +	line.  Note that tags are not pushed automatically.

That is implicit in the line before it. In any case: The main problem of
git-push(1) seems to be that one has to read all the way down (through
all options) in order to grasp the default case, so I feel the first
paragraph needs to improve.

>  
>  --receive-pack=<git-receive-pack>::
>  --exec=<git-receive-pack>::
> 

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Steffen Daode Nurpmeso]

@ Michael J Gruber <git@drmicha.warpmail.net> wrote (2011-06-07 07:47+0200):
> > +	refs under `refs/heads/` be pushed explicitely.
> 
> I don't mind but I don't think it adds clarity.

Yes you're right - it was around midnight and i was tired.
That's a stupid change.

> That is implicit in the line before it. In any case: The main problem of
> git-push(1) seems to be that one has to read all the way down (through
> all options) in order to grasp the default case, 

In fact i'm lazy, so i'll assume that hardly happens until the
first error occurs :).

> so I feel the first paragraph needs to improve.

This morning i've reread tutorial(-2)? and user-manual, which,
plus core-tutorial, where the files i've really read :-).
And guess what, in neither of these files you will find a single
word or even example about this, but the talk is only on branches!
everyday.txt and gitworkflows.txt, however, give you

    <13> push the tag out, too.
..
    You need to push the new tag to a public git serve..
    This makes the tag available

Interesting ", too" and "You need to" that is, maybe ;-/.
I'll propose for real fewest minor changes in the documentation,
so that users get a glance on that fact.  I would assume that
these few lines would have been enough for me to "get a starter".

Thanks for the responses.
(By the way: "an arbitrary SHA-1 expression will do" sounds like
it's talking about a cool and flexible software.)
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Victor Engmark]

On Mon, Jun 06, 2011 at 04:31:50PM +0200, Michael J Gruber wrote:
> Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:
> > Hello GIT,
> >     first paragraph is reserved for praising your existence.
> >     'Used cvs(1) for long years in small team projects with local
> >     private repos and never felt the need for anything else.  2011
> >     is different.  I first tried you but failed resoundingly.  Due
> >     to vim(1) and mutt(1) i discovered hg(1) and i still love it's
> >     simple usage.  'Talking about the front-end anyway.  It's huge
> >     memory consumption and slow performance forbids it's usage on
> >     our old PCs (e.g. Cyrix 166+) though.  So i came back and
> >     found you still receptive!  And the more i work, the less
> >     i hurt, the greater the knowledge, the smoother the
> >     interaction.  Are you the final word on RC in the end?
> > 
> > I stumbled over one thing i don't understand, because it seems
> > illogical: why do i need to use --tags to force pushing of tags?
> > Because there is even a config option for the latter, i suspect
> > this is because of intention.  It would be nice to get some
> > information on the background of that, like a link to yet existing
> > documentation.  Anyway i was a bit astonished to look at some
> 
> Tags may contain private information. Say you pull some changes from
> your head of group, find a strange commit you want to look at later and
> tag it with "what-is-this-crap"...

You could use the same argument about commit log messages, branch names
and code comments. No go ;)

> More seriously, tags are not part of the "remotes layout", so when you
> push them and others pull them they overwrite their tags if there's a
> name clash.

That's odd - I wouldn't expect anything handled by Git to be simply
overwritten without merging. Is there some technical reason for this, or
is it just not implemented yet?

If it makes more sense to casual users, how about simply making --tags
the default, and --no-tags optional?

Cheers
-- 
Victor
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch

Wir sichern Ihren Erfolg - seit 15 Jahren

Re: Jabber, question on push,pull and --tags, and no help but jabber

[Junio C Hamano]

Victor Engmark <victor.engmark@terreactive.ch> writes:

>> More seriously, tags are not part of the "remotes layout", so when you
>> push them and others pull them they overwrite their tags if there's a
>> name clash.
>
> That's odd - I wouldn't expect anything handled by Git to be simply
> overwritten without merging. Is there some technical reason for this, or
> is it just not implemented yet?

Branches are something you work on by looking at other people's progress,
so remote layout to copy his master branch to refs/remotes/his/master so
that you can compare it with yours with "git diff his/master master" or
merge his effort into yours with "git merge his/master" makes sense.

Tags are something that is to be _shared_ amongst people, and having v1.4.3
that is different depending on which member of the same project you ask is
a road to insanity, hence we don't do refs/remotes/his/v1.4.3 that could
be different from the project's global refs/tags/v1.4.3 to reduce the risk
of confusion.

[PATCH] Notes that tags need to pushed explicitely

[Steffen Daode Nurpmeso]

---
 Documentation/git-tag.txt     |    3 ++-
 Documentation/gittutorial.txt |    1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index d82f621..242837f 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the
 If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
 creates a 'tag' object, and requires a tag message.  Unless
 `-m <msg>` or `-F <file>` is given, an editor is started for the user to type
-in the tag message.
+in the tag message.  Tag objects can be pushed upstream with
+linkgit:git-push[1].
 
 If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
 are absent, `-a` is implied.
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 0982f74..08c0c3a 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -520,6 +520,7 @@ names.  For example:
 
 -------------------------------------
 $ git diff v2.5 HEAD	 # compare the current HEAD to v2.5
+$ git push v2.5		 # push the tag upstream
 $ git branch stable v2.5 # start a new branch named "stable" based
 			 # at v2.5
 $ git reset --hard HEAD^ # reset your current branch and working
-- 
1.7.6.rc0

Re: [PATCH] Notes that tags need to pushed explicitely

[Junio C Hamano]

Steffen Daode Nurpmeso <sdaoden@googlemail.com> writes:

> ---

Sign-off?

>  Documentation/git-tag.txt     |    3 ++-
>  Documentation/gittutorial.txt |    1 +
>  2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
> index d82f621..242837f 100644
> --- a/Documentation/git-tag.txt
> +++ b/Documentation/git-tag.txt
> @@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the
>  If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
>  creates a 'tag' object, and requires a tag message.  Unless
>  `-m <msg>` or `-F <file>` is given, an editor is started for the user to type
> -in the tag message.
> +in the tag message.  Tag objects can be pushed upstream with
> +linkgit:git-push[1].
>  
>  If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
>  are absent, `-a` is implied.

This part of the patch looks sane and uncontroversial.

> diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
> index 0982f74..08c0c3a 100644
> --- a/Documentation/gittutorial.txt
> +++ b/Documentation/gittutorial.txt
> @@ -520,6 +520,7 @@ names.  For example:
>  
>  -------------------------------------
>  $ git diff v2.5 HEAD	 # compare the current HEAD to v2.5
> +$ git push v2.5		 # push the tag upstream
>  $ git branch stable v2.5 # start a new branch named "stable" based
>  			 # at v2.5
>  $ git reset --hard HEAD^ # reset your current branch and working

This feels way out of place in the context of the story the tutorial is
telling. These are examples that various ways to spell object names are
used to identify a commit to commands that want to be given commits, but
"git push <tagname>" is _not_ an example of such a command.  Also there is
nothing in the vicinity that pushes a branch that contains the tagged
commit out; if the earlier example to create this v2.5 tag were done to
mark a commit in an existing history you obtained from elsewhere, pushing
the tag alone might make sense, but usually you push branches out and then
optionally tags that refer to commits on those branches.

How about adding an example in git-push section instead?

 Documentation/git-push.txt |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 88acfcd..363d3df 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -371,6 +371,11 @@ git push origin HEAD:master::
 	`origin` repository. This form is convenient to push the current
 	branch without thinking about its local name.
 
+git push origin tag v1.5::
+	Push the `v1.5` tag to the `origin` repository. A newly created
+	tag needs to be published explicitly like this, just like a newly
+	created branch does not get published automatically.
+
 git push origin master:refs/heads/experimental::
 	Create the branch `experimental` in the `origin` repository
 	by copying the current `master` branch.  This form is only

[PATCH] Remarks that tags need to be pushed explicitly

[Steffen Daode Nurpmeso]

@ Junio C Hamano <gitster@pobox.com> wrote (2011-06-07 16:12+0200):
> > diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
> This feels way out of place in the context of the story the tutorial is
> telling.

No door gap at all for this in *tut* and user-manual!

> How about adding an example in git-push section instead?

I'll pack this in verbatim.  :).
You'll notice that the patch also adds the word "Utilize" in front
of `tag <tag>` in the OPTIONS section.  I did not even now that
the term "tag" can be used, but i'm afraid that i thought of that
as a spelling error - on my terminal all these `terms` are not
highlighted in any special way.  'Would thus be good?
__
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments


Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
---
 Documentation/git-push.txt |    7 ++++++-
 Documentation/git-tag.txt  |    3 ++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 88acfcd..898348a 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -55,7 +55,7 @@ you can tell git to update the <dst> ref even when the update is not a
 fast-forward.  This does *not* attempt to merge <src> into <dst>.  See
 EXAMPLES below for details.
 +
-`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+Utilize `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
 +
 Pushing an empty <src> allows you to delete the <dst> ref from
 the remote repository.
@@ -371,6 +371,11 @@ git push origin HEAD:master::
 	`origin` repository. This form is convenient to push the current
 	branch without thinking about its local name.
 
+git push origin tag v1.5::
+       Push the `v1.5` tag to the `origin` repository. A newly created
+       tag needs to be published explicitly like this, just like a newly
+       created branch does not get published automatically.
+
 git push origin master:refs/heads/experimental::
 	Create the branch `experimental` in the `origin` repository
 	by copying the current `master` branch.  This form is only
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index d82f621..242837f 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the
 If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
 creates a 'tag' object, and requires a tag message.  Unless
 `-m <msg>` or `-F <file>` is given, an editor is started for the user to type
-in the tag message.
+in the tag message.  Tag objects can be pushed upstream with
+linkgit:git-push[1].
 
 If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
 are absent, `-a` is implied.
-- 
1.7.6.rc0

[PATCH v2] Remarks that tags need to be pushed explicitly

[Steffen Daode Nurpmeso]

Well here is a somewhat more sophisticated version of this tiny
documentation patch.  I believe this is a good thing now for
newbie users who have not yet created any git(1) specific synapses
(except for the term "branch-related <refspec>", but "any valid
<refspec>" is a bit misleading since you will see nowhere that
"ref/tags/*" is not a valid <refspec> unless you know this is
a logical thing; heroes may know at a glance).

I don't like gitworkflows.txt as a direct link after tutorial and
tutorial-2.  It's much too specialized in my eyes.  What is really
missing here is a tutorial-3 which only talks about, and gives
myriads of examples for pull/fetch and push, including easy
configuration examples and corner cases (like "ref/tags/*").
Maybe in six month or a bit later i have gathered enough knowledge
to be able to write that in theory.  :)

P.S.: And please forget that 'tag --autopush' idea.  Not even
'tag --autopush-to=REMOTE' seems to be sensible to me anymore
(because it's much easier to script that locally than to support
that in git(1)).

Have a nice weekend (if you can).
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

-- >8 --
An updated patch of the try to smoothly integrate some more
easy informations about pushing of tags.

Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
---
 Documentation/git-push.txt    |   10 +++++++---
 Documentation/git-tag.txt     |    4 +++-
 Documentation/user-manual.txt |    6 +++---
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 88acfcd..e3af6da 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -55,7 +55,7 @@ you can tell git to update the <dst> ref even when the update is not a
 fast-forward.  This does *not* attempt to merge <src> into <dst>.  See
 EXAMPLES below for details.
 +
-`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+Use of `tag <tag>` is identical to `refs/tags/<tag>:refs/tags/<tag>`.
 +
 Pushing an empty <src> allows you to delete the <dst> ref from
 the remote repository.
@@ -340,8 +340,8 @@ The default behavior of this command when no <refspec> is given can be
 configured by setting the `push` option of the remote.
 +
 For example, to default to pushing only the current branch to `origin`
-use `git config remote.origin.push HEAD`.  Any valid <refspec> (like
-the ones in the examples below) can be configured as the default for
+use `git config remote.origin.push HEAD`.  Any valid branch-related <refspec>
+(like the ones in the examples below) can be configured as the default for
 `git push origin`.
 
 git push origin :::
@@ -371,6 +371,10 @@ git push origin HEAD:master::
 	`origin` repository. This form is convenient to push the current
 	branch without thinking about its local name.
 
+git push origin tag v1.5::
+	Push the `v1.5` tag to the `origin` repository.
+	Short hand for `git push origin refs/tags/v1.5:refs/tags/v1.5`.
+
 git push origin master:refs/heads/experimental::
 	Create the branch `experimental` in the `origin` repository
 	by copying the current `master` branch.  This form is only
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index d82f621..a4cd4c3 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -27,7 +27,8 @@ Unless `-f` is given, the tag to be created must not yet exist in the
 If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
 creates a 'tag' object, and requires a tag message.  Unless
 `-m <msg>` or `-F <file>` is given, an editor is started for the user to type
-in the tag message.
+in the tag message.  Tag objects are shareable and can be pushed upstream with
+linkgit:git-push[1].
 
 If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
 are absent, `-a` is implied.
@@ -260,6 +261,7 @@ include::date-formats.txt[]
 
 SEE ALSO
 --------
+linkgit:git-push[1].
 linkgit:git-check-ref-format[1].
 
 GIT
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f13a846..168e530 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -643,9 +643,9 @@ $ git tag stable-1 1b2e1d63ff
 You can use stable-1 to refer to the commit 1b2e1d63ff.
 
 This creates a "lightweight" tag.  If you would also like to include a
-comment with the tag, and possibly sign it cryptographically, then you
-should create a tag object instead; see the linkgit:git-tag[1] man page
-for details.
+comment with the tag, possibly sign the tag cryptographically, or publish the
+tag in a shared repository, then you should create a tag object instead; see
+the linkgit:git-tag[1] man page for details.
 
 [[browsing-revisions]]
 Browsing revisions
-- 
1.7.6.rc0

Re: [PATCH v2] Remarks that tags need to be pushed explicitly

[Junio C Hamano]

Steffen Daode Nurpmeso <sdaoden@googlemail.com> writes:

> (except for the term "branch-related <refspec>", but "any valid
> <refspec>" is a bit misleading since you will see nowhere that
> "ref/tags/*" is not a valid <refspec> unless you know this is
> a logical thing; heroes may know at a glance).

Sorry, I do not understand this paragraph, nor why the hunk in your patch
that corresponds to this comment, is a good change.

The current document says that any valid <refspec> can be configured as
the default to push for 'git push backup', so you could say

    [remote "backup"]
	url = /mnt/backup/my-project.git/
    	push = +refs/heads/*:refs/heads/*
        push = +refs/tags/*:refs/tags/*

in your configuration file, and "git push backup" would save the branches
and tags to your backup location.

Why should this paragraph discourage users to configure refspec that talk
about refs outside branch-related things?

> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 88acfcd..e3af6da 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> ...
> @@ -340,8 +340,8 @@ The default behavior of this command when no <refspec> is given can be
>  configured by setting the `push` option of the remote.
>  +
>  For example, to default to pushing only the current branch to `origin`
> -use `git config remote.origin.push HEAD`.  Any valid <refspec> (like
> -the ones in the examples below) can be configured as the default for
> +use `git config remote.origin.push HEAD`.  Any valid branch-related <refspec>
> +(like the ones in the examples below) can be configured as the default for
>  `git push origin`.


> @@ -371,6 +371,10 @@ git push origin HEAD:master::
>  	`origin` repository. This form is convenient to push the current
>  	branch without thinking about its local name.
>  
> +git push origin tag v1.5::
> +	Push the `v1.5` tag to the `origin` repository.
> +	Short hand for `git push origin refs/tags/v1.5:refs/tags/v1.5`.

Existing documentation seems to say either "shorthand" (22 occurrences) or
"short-hand" (12 occurrences).

> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index f13a846..168e530 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -643,9 +643,9 @@ $ git tag stable-1 1b2e1d63ff
>  You can use stable-1 to refer to the commit 1b2e1d63ff.
>  
>  This creates a "lightweight" tag.  If you would also like to include a
> -comment with the tag, and possibly sign it cryptographically, then you
> -should create a tag object instead; see the linkgit:git-tag[1] man page
> -for details.
> +comment with the tag, possibly sign the tag cryptographically, or publish the
> +tag in a shared repository, then you should create a tag object instead; see
> +the linkgit:git-tag[1] man page for details.

Addition of "possibly sign" is a good change, but it is perfectly OK to
publish a lightweight tag by pushing it into a remote repository via "git
push", so "if you want to publish, you should create a tag object instead"
is a misguided suggestion.

Other than that, the patch looks Ok to me.

Thanks.

Re: [PATCH v2] Remarks that tags need to be pushed explicitly

[Steffen Daode Nurpmeso]

@ Junio C Hamano <gitster@pobox.com> wrote (2011-06-10 23:24+0200):
> Thanks.

I'm simply completely missing the point sofar.
Sorry for the noise, all of you.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments