[PATCH] Documentation: git-tag '-m' implies '-a'

[PATCH] Documentation: git-tag '-m' implies '-a'

[Dirk Süsserott]

Described that '-a' is implied when '-m' or '-F' is present.
---
 Documentation/git-tag.txt |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b62a3d1..c22fb71 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -26,6 +26,9 @@ creates a 'tag' object, and requires the tag message.  
Unless
 `-m <msg>` or `-F <file>` is given, an editor is started for the user 
to type
 in the tag message.
 
+If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
+are absent, `-a` is implied.
+
 Otherwise just the SHA1 object name of the commit object is
 written (i.e. a lightweight tag).
 
@@ -68,10 +71,14 @@ OPTIONS
     Use the given tag message (instead of prompting).
     If multiple `-m` options are given, there values are
     concatenated as separate paragraphs.
+    Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+    is given.
 
 -F <file>::
     Take the tag message from the given file.  Use '-' to
     read the message from the standard input.
+    Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+    is given.
 
 CONFIGURATION
 -------------
-- 
1.5.4.950.ga176

[PATCH] Documentation: git-tag '-m' implies '-a'

[Jeff King]

From: Dirk Süsserott <newsletter@dirk.my1.cc>

Described that '-a' is implied when '-m' or '-F' is present.
---
On Mon, Mar 24, 2008 at 03:41:54PM +0100, Dirk Süsserott wrote:

> Described that '-a' is implied when '-m' or '-F' is present.

Oh, I see you already took my suggestion before I made it. :)

The text looks good to me, but the patch would not apply here. I think
there are some wrapping issues, and it looks like some tabs have been
mangled to spaces.

Also, it is generally a good idea to:
  - at least cc Junio on patch submissions to make sure he sees it
  - sign off your patch (either with commit -s or format-patch -s).

Here is an unmangled version of the patch.

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

diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b62a3d1..c22fb71 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -26,6 +26,9 @@ creates a 'tag' object, and requires the tag message.  Unless
 `-m <msg>` or `-F <file>` is given, an editor is started for the user to type
 in the tag message.
 
+If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
+are absent, `-a` is implied.
+
 Otherwise just the SHA1 object name of the commit object is
 written (i.e. a lightweight tag).
 
@@ -68,10 +71,14 @@ OPTIONS
 	Use the given tag message (instead of prompting).
 	If multiple `-m` options are given, there values are
 	concatenated as separate paragraphs.
+	Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+	is given.
 
 -F <file>::
 	Take the tag message from the given file.  Use '-' to
 	read the message from the standard input.
+	Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+	is given.
 
 CONFIGURATION
 -------------
-- 
1.5.5.rc1.123.ge5f4e6

Re: [PATCH] Documentation: git-tag '-m' implies '-a'

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> From: Dirk Süsserott <newsletter@dirk.my1.cc>
>
> Described that '-a' is implied when '-m' or '-F' is present.
> ---
> On Mon, Mar 24, 2008 at 03:41:54PM +0100, Dirk Süsserott wrote:
>
>> Described that '-a' is implied when '-m' or '-F' is present.
>
> Oh, I see you already took my suggestion before I made it. :)
>
> The text looks good to me, but the patch would not apply here. I think
> there are some wrapping issues, and it looks like some tabs have been
> mangled to spaces.

Thanks for tidying up.  It makes my life easier.

> Also, it is generally a good idea to:
>   - at least cc Junio on patch submissions to make sure he sees it
>   - sign off your patch (either with commit -s or format-patch -s).

Heh, and you did not sign it off when you forwarded? ;-)

Re: [PATCH] Documentation: git-tag '-m' implies '-a'

[Jeff King]

On Mon, Mar 24, 2008 at 01:07:15PM -0700, Junio C Hamano wrote:

> Thanks for tidying up.  It makes my life easier.

No problem.

> >   - at least cc Junio on patch submissions to make sure he sees it
> >   - sign off your patch (either with commit -s or format-patch -s).
> 
> Heh, and you did not sign it off when you forwarded? ;-)

Heh. Believe it or not, that actually did occur to me. However, I'm not
really sure what it means to do that. As you have made clear in the
past, the signoff is _not_ "this looks good to me, please apply" but
rather "I am signing the Certificate of Origin."

And while I can only assume that everything in such an obvious patch is
kosher, it is _not_ true that:

  - I created or have the right to submit it under an open source
    license (DCO, part a)
  - The contribution was provided to me by somebody else who certified
    the above (DCO, part c)

I'm not clear on what part (b) of the DCO means. Is it making a
judgement that says "even though I have no license on this, it is
clearly a derivative work of git, which is GPL'd, and therefore it is
GPL'd"?

-Peff

Re: [PATCH] Documentation: git-tag '-m' implies '-a'

[Dirk Süsserott]

Jeff, thanks for the advice and the corrections, I'll act on it.
It was my first submission and I'm handicapped in the way that I'm
using Windows. So I just pasted the patch into my Thunderbird window.

The git-send-email program doesn't work properly with Windows.
Either the sendmail program isn't present (no shit sherlock ;-))
or the Net/SMTP.pm module isn't found. I'm currently writing
a wrapper to bypass that. When I manage to figure the problem,
I'll post a patch.

git-send-email for Windows doesn't accept the authorization
switches (--smtp-user, --smtp-pass) (despite the docs), so I've
either to patch it or use a wrapper that adds them.

Dirk


Jeff King schrieb:
> On Mon, Mar 24, 2008 at 01:07:15PM -0700, Junio C Hamano wrote:
>
>   
>> Thanks for tidying up.  It makes my life easier.
>>     
>
> No problem.
>
>   
>>>   - at least cc Junio on patch submissions to make sure he sees it
>>>   - sign off your patch (either with commit -s or format-patch -s).
>>>       
>> Heh, and you did not sign it off when you forwarded? ;-)
>>     
>
> Heh. Believe it or not, that actually did occur to me. However, I'm not
> really sure what it means to do that. As you have made clear in the
> past, the signoff is _not_ "this looks good to me, please apply" but
> rather "I am signing the Certificate of Origin."
>
> And while I can only assume that everything in such an obvious patch is
> kosher, it is _not_ true that:
>
>   - I created or have the right to submit it under an open source
>     license (DCO, part a)
>   - The contribution was provided to me by somebody else who certified
>     the above (DCO, part c)
>
> I'm not clear on what part (b) of the DCO means. Is it making a
> judgement that says "even though I have no license on this, it is
> clearly a derivative work of git, which is GPL'd, and therefore it is
> GPL'd"?
>
> -Peff
>
>