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

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

Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 15:02:

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.

"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

On Mon, Jun 6, 2011 at 5:31 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Until tag namespaces are merged.

@ Michael J Gruber <git@drmicha.warpmail.net> wrote (2011-06-06 16:31+0200):

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

--

Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 23:46:

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.

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

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:

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.

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

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.

@ Michael J Gruber <git@drmicha.warpmail.net> wrote (2011-06-07 07:47+0200):

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

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

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

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

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

Sign-off?

This part of the patch looks sane and uncontroversial.

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

@ Junio C Hamano <gitster@pobox.com> wrote (2011-06-07 16:12+0200):

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

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

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

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

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?

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

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.

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

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

On Mon, Jun 06, 2011 at 04:31:50PM +0200, Michael J Gruber wrote:

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

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 Engmark <victor.engmark@terreactive.ch> writes:

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.