some git-commands --help don't act like git commands --help

some git-commands --help don't act like git commands --help

[jidanni]

Hmmm, some git-commands --help act just like git commands --help,
$ git commit --help 2>&1|wc -l
336
$ git-commit --help 2>&1|wc -l
336

But others don't
$ git am --help 2>&1|wc -l
152
$ git-am --help 2>&1|wc -l
19

$ git --version
git version 1.5.6.5
on Debian sid.

Re: some git-commands --help don't act like git commands --help

[Nanako Shiraishi]

Quoting jidanni@jidanni.org:

> Hmmm, some git-commands --help act just like git commands --help,
> $ git commit --help 2>&1|wc -l
> 336
> $ git-commit --help 2>&1|wc -l
> 336
>
> But others don't
> $ git am --help 2>&1|wc -l
> 152
> $ git-am --help 2>&1|wc -l
> 19

Thank you for your observation; what do you want to do about it?

Are you complaining that some commands do not have customized description that is not as long as the full manual page but not as terse as the short help "-h" output? Or are you complaining some other commands do not give you full manual pages for "--help"?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: some git-commands --help don't act like git commands --help

[Michael Gaber]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Nanako Shiraishi schrieb:
> Quoting jidanni@jidanni.org:
> 
>> Hmmm, some git-commands --help act just like git commands --help,
>> $ git commit --help 2>&1|wc -l
>> 336
>> $ git-commit --help 2>&1|wc -l
>> 336
>>
>> But others don't
>> $ git am --help 2>&1|wc -l
>> 152
>> $ git-am --help 2>&1|wc -l
>> 19
> 
> Thank you for your observation; what do you want to do about it?
> 
> Are you complaining that some commands do not have customized description that is not as long as the full manual page but not as terse as the short help "-h" output? Or are you complaining some other commands do not give you full manual pages for "--help"?
> 

I think he just wantet to state that the output of git-command --help
and git command --help should be identical as the both do the same
thing, don't they?

Regards Michael

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3656 bytes --]

Re: some git-commands --help don't act like git commands --help

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting jidanni@jidanni.org:
>
>> Hmmm, some git-commands --help act just like git commands --help,
>> $ git commit --help 2>&1|wc -l
>> 336
>> $ git-commit --help 2>&1|wc -l
>> 336
>>
>> But others don't
>> $ git am --help 2>&1|wc -l
>> 152
>> $ git-am --help 2>&1|wc -l
>> 19
>
> Thank you for your observation; what do you want to do about it?
>
> Are you complaining that some commands do not have customized description that is not as long as the full manual page but not as terse as the short help "-h" output? Or are you complaining some other commands do not give you full manual pages for "--help"?

I think he is comparing "git am" and "git-am" the latter of which is now
deprecated and largely removed from the end user.

IOW, the seeming inconsistency is not an issue anymore in practice in the
post 1.6.0 era.

"git-whatever" the new style vs. "git whatever"?

[jidanni]

JCH> I think he is comparing "git am" and "git-am" the latter of which is now
JCH> deprecated and largely removed from the end user.

By the way, we here at the end user end have a hard time detecting if
"git-whatever" the new style vs. "git whatever"...

Idea: right at top of "man git" say: You might have noticed sometimes
people write "git-whatever" and sometimes write "git whatever", well ...

JCH> IOW, the seeming inconsistency is not an issue anymore in practice in the
JCH> post 1.6.0 era.

(I was just hoping everything is consistent, one way or the other.)

Re: "git-whatever" the new style vs. "git whatever"?

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Monday 2008 December 29 13:37:19 jidanni@jidanni.org wrote:
> JCH> I think he is comparing "git am" and "git-am" the latter of which is
> JCH> now deprecated and largely removed from the end user.
>
> By the way, we here at the end user end have a hard time detecting if
> "git-whatever" the new style vs. "git whatever"...

That shouldn't be a problem for much longer because "git-whatever" will stop 
working.  From what I understand, "git whatever" has always been the 
preferred form, and the fact that "git-whatever" worked was just a 
implementation detail.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: "git-whatever" the new style vs. "git whatever"?

[A Large Angry SCM]

Boyd Stephen Smith Jr. wrote:
> On Monday 2008 December 29 13:37:19 jidanni@jidanni.org wrote:
>> JCH> I think he is comparing "git am" and "git-am" the latter of which is
>> JCH> now deprecated and largely removed from the end user.
>>
>> By the way, we here at the end user end have a hard time detecting if
>> "git-whatever" the new style vs. "git whatever"...
> 
> That shouldn't be a problem for much longer because "git-whatever" will stop 
> working.  From what I understand, "git whatever" has always been the 
> preferred form, and the fact that "git-whatever" worked was just a 
> implementation detail.

This is a revisionist history. Check the history of the git command to 
find out when it was created and then check the ML archives for related 
discussions.

Re: "git-whatever" the new style vs. "git whatever"?

[jidanni]

>> That shouldn't be a problem for much longer because "git-whatever"
>> will stop working.  From what I understand, "git whatever" has
>> always been the preferred form, and the fact that "git-whatever"
>> worked was just a implementation detail.

I thought if A worked from the start, and now B also works, you all
must have been moving to B, and so I made all my shell scripts use B.

ALAS> This is a revisionist history. Check the history of the git command to
ALAS> find out when it was created and then check the ML archives for
ALAS> related discussions.

All I know is we beginners just encounter both forms in the literature
and won't know about looking into whatever histories... and assumed until
this post that git-whatever was the new style! OK, now I know the truth.

Re: "git-whatever" the new style vs. "git whatever"?

[jidanni]

I swear we new users would have never guessed that git-whatever was
yes the new, but _deprecated_ style, until we asked on this newslist,
and today chucked Debian sid for Debian experimental, to see the
following. OK. Good to finally know. I feel sorry for all the Debian
Sid users who haven't heard the news and are putting the soon to break
form into their scripts and newsposts. Indeed, you on the mailing list
could point out to any users that what they just posted is going to
break soon.

Wait, e.g., git commit --help, man git-commit, etc. are still full of
the old notation here now in 1.6.0...

--- News for git-core (git-core git-email gitk) ---
git-core (1:1.6.0-1) experimental; urgency=low

  Most of the programs are now installed outside the default $PATH,
  except for "git", "gitk" and some server side programs that need
  to be accessible for technical reasons.  Invoking a git subcommand
  as "git-xyzzy" from the command line has been deprecated since
  early 2006 (and officially announced in the 1.5.4 release notes);
  using the "git-xyzzy" form in scripts after adding the output from
  "git --exec-path" to the $PATH is still supported in this release,
  but users are again strongly encouraged to adjust their scripts to
  use the "git xyzzy" form, as this support might be dropped in later
  releases.

 -- Gerrit Pape <pape@smarden.org>  Sun, 24 Aug 2008 22:31:44 +0000

Re: some git-commands --help don't act like git commands --help

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>:

> I think he is comparing "git am" and "git-am" the latter of which is now
> deprecated and largely removed from the end user.
>
> IOW, the seeming inconsistency is not an issue anymore in practice in the
> post 1.6.0 era.

Ah, I misread that distinction in the OP's message.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/