Steffen Daode Nurpmeso venit, vidit, dixit 06.06.2011 23:46: > @ Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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>:: > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html