eth

eth

[Kevin Geiss]

---

 git-cvsexportcommit.perl |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

applies-to: e604d20cd75e71750e8316348c988ef0296b3ec5
224d4f4897ea47425aafc6d491f2a0762e683a4c
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 50b041c..5bce39c 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -4,6 +4,7 @@ use strict;
 use Getopt::Std;
 use File::Temp qw(tempdir);
 use Data::Dumper;
+use File::Basename qw(basename);
 
 unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
     die "GIT_DIR is not defined or is unreadable";
@@ -206,8 +207,7 @@ if ($opt_c) {
 }
 sub usage {
 	print STDERR <<END;
-Usage: GIT_DIR=/path/to/.gi ${\basename $0}      # fetch/update GIT from CVS
-       [-h] [-p] [ parent ] commit
+Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [ parent ] commit
 END
 	exit(1);
 }
---
0.99.9.GIT

[PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.

[Kevin Geiss]

---

 git-cvsexportcommit.perl |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

applies-to: e604d20cd75e71750e8316348c988ef0296b3ec5
224d4f4897ea47425aafc6d491f2a0762e683a4c
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 50b041c..5bce39c 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -4,6 +4,7 @@ use strict;
 use Getopt::Std;
 use File::Temp qw(tempdir);
 use Data::Dumper;
+use File::Basename qw(basename);
 
 unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
     die "GIT_DIR is not defined or is unreadable";
@@ -206,8 +207,7 @@ if ($opt_c) {
 }
 sub usage {
 	print STDERR <<END;
-Usage: GIT_DIR=/path/to/.gi ${\basename $0}      # fetch/update GIT from CVS
-       [-h] [-p] [ parent ] commit
+Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [ parent ] commit
 END
 	exit(1);
 }
---
0.99.9.GIT

Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.

[Kevin Geiss]

this was supposed to be 1/4 of course.

Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.

[Junio C Hamano]

Kevin Geiss <kevin@desertsol.com> writes:

>  sub usage {
>  	print STDERR <<END;
> -Usage: GIT_DIR=/path/to/.gi ${\basename $0}      # fetch/update GIT from CVS
> -       [-h] [-p] [ parent ] commit
> +Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [ parent ] commit
>  END
>  	exit(1);
>  }

I hate to be nitpicky, but this slurps in File::Basename
(9Kbytes) only to shorten the displayed command name.

I personally do not like programs that shorten $0 (or in C
argv[0]) when they identify themselves.  This is probably just
me, but I was bitten by such programs too many times while
debugging them, after wasting too many hours only to find that I
was not running the executable I thought I was running but
something else that happened to be earlier on my PATH X-<.

Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.

[Martin Langhoff]

On 11/15/05, Junio C Hamano <junkio@cox.net> wrote:
> I hate to be nitpicky, but this slurps in File::Basename
> (9Kbytes) only to shorten the displayed command name.

Fair enough -- I'll leave that one up to you. I'm happy with Kevin's
patches -- what's the ideal workflow for this? Is the sign-off line
important enough that I should setup a public repo for you to pull
from?

BTW, File::Basename is a standard library usually installed w perl -- 
it shouldn't add any painful dependencies. Not sure if that matters.


martin

Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.

[Junio C Hamano]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> ... I'm happy with Kevin's patches -- what's the ideal
> workflow for this? Is the sign-off line important enough that
> I should setup a public repo for you to pull from?

Given that you are far more familiar with that part of the code,
and I suspect I'd be asking your help in archimport as well, a
repo I can pull from would be more preferable (and sign-off by
you is certainly an added bonus).  If a public repo is too much
hassle, however, e-mail forwarding is perfectly fine as well.
Your choice.

BTW, there is no "mana" points involved in deciding if I
directly pull from somewhere.  Even if that were the case, you
have accumulated enough of them already ;-).

> BTW, File::Basename is a standard library usually installed w perl -- 
> it shouldn't add any painful dependencies. Not sure if that matters.

Although some might find "${\function}" expansion too cute for
their taste, Keven's code is fine as-is for me.  I launched the
baloon just wanting to see what others have to say ;-).

Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.

[Martin Langhoff]

On 11/15/05, Junio C Hamano <junkio@cox.net> wrote:
> Given that you are far more familiar with that part of the code,
> and I suspect I'd be asking your help in archimport as well, a
> repo I can pull from would be more preferable (and sign-off by
> you is certainly an added bonus).  If a public repo is too much
> hassle, however, e-mail forwarding is perfectly fine as well.
> Your choice.

It is _easy_. I've setup a server for git-related paraphernalia at
work already ;)

The URL is:
  http://locke.catalyst.net.nz/git/git-martinlanghoff.git/#tojunio

gitweb at:
  http://locke.catalyst.net.nz/gitweb?p=git-martinlanghoff.git;a=summary

That gitweb has per-branch RSS feeds, if you are an rss junkio ;-) you
can just subscribe to it...

A word of warning, though: those branches rewind/rebase often, and I
won't apologise about it. You should be able to just delete your
'martinlanghoff' head and refetch it. Anyone else reading this... just
_don't_ base your work on my branch as it's bound to break.

> BTW, there is no "mana" points involved in deciding if I
> directly pull from somewhere.  Even if that were the case, you
> have accumulated enough of them already ;-).

:-)

/me is happy that you've forgotten about my brown-paper-bag patch with
a random character in the middle!

> Although some might find "${\function}" expansion too cute for
> their taste, Keven's code is fine as-is for me.  I launched the
> baloon just wanting to see what others have to say ;-).

Fine w me -- TIMTOWDI. I do understand, however, your interest in
having full paths in the usage line to make debugging easier. Whatever
is consistent with the project in general.

cheers,


martin

Re: eth

[Kevin Geiss]

oops, I munged up the subject on this one. I resent it with '1/1' in the subject. :(

On Mon, Nov 14, 2005 at 09:40:47AM -0700, Kevin Geiss wrote: