Re: strict version of version_stamp.pl

Hello,

Here is a diff of version_stamp.pl. It is not quite done as I can't
actually get it to run. No matter what I do it doesn't appear to be able
to open configure.in.

If someone could help me figure out where I am being stupid I would
appreciate it.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Here is a diff of version_stamp.pl.

... and nearly a megabyte of irrelevant junk. Please take a closer look at
what you're sending before you send it ...

regards, tom lane

On Fri, 2009-05-08 at 14:16 -0700, Joshua D. Drake wrote:
> Hello,
>
> Here is a diff of version_stamp.pl. It is not quite done as I can't
> actually get it to run. No matter what I do it doesn't appear to be able
> to open configure.in.
>
> If someone could help me figure out where I am being stupid I would
> appreciate it.

Well you can all start by pointing out that I included a patch to
configure (which was wholly unintended). Sorry about that. Here is the
straight perl patch.

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > Here is a diff of version_stamp.pl.
>
> ... and nearly a megabyte of irrelevant junk. Please take a closer look at
> what you're sending before you send it ...

Yes I apologize for that. Git reacted differently than I expected to a
"git diff". I have since reposted a proper patch.

/me walks away in shame

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > Here is a diff of version_stamp.pl.
>
> ... and nearly a megabyte of irrelevant junk. Please take a closer look at
> what you're sending before you send it ...

Never mind on this. I have obviously not re-honed my perl skills enough
to handle this.

Sorry for the noise.

Joshua D. Drake

>
> regards, tom lane
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Yes I apologize for that. Git reacted differently than I expected to a
> "git diff". I have since reposted a proper patch.

mmm ... I've recently been forced into using git for another project,
and I find myself mystified as to why anyone would want to use it.
Seems like baroqueness and unexpected behaviors are all over the thing.

regards, tom lane

On Saturday 09 May 2009 00:50:28 Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > Yes I apologize for that. Git reacted differently than I expected to a
> > "git diff". I have since reposted a proper patch.
>
> mmm ... I've recently been forced into using git for another project,
> and I find myself mystified as to why anyone would want to use it.
> Seems like baroqueness and unexpected behaviors are all over the thing.

Obviously, an unchecked cvs diff would have produced the same garbage. Any
other problems?

On Sat, 2009-05-09 at 01:18 +0300, Peter Eisentraut wrote:
> On Saturday 09 May 2009 00:50:28 Tom Lane wrote:
> > "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > > Yes I apologize for that. Git reacted differently than I expected to a
> > > "git diff". I have since reposted a proper patch.
> >
> > mmm ... I've recently been forced into using git for another project,
> > and I find myself mystified as to why anyone would want to use it.
> > Seems like baroqueness and unexpected behaviors are all over the thing.
>
> Obviously, an unchecked cvs diff would have produced the same garbage. Any
> other problems?

There are a number of conceptual differences. For example as a majority
svn user, svn diff does not act the way git diff does. In that svn diff
will only give me the difference within the current working directory.
It will not go to the beginning of the tree and give me a diff.

Perhaps a more difficult problem is that there is no easy way to update
a single file within a git repo. In cvs or svn, if I blow something up
on a particular file and I just want to take a fresh look, I just rm;svn
update.

Those are two things I can think of from my own working perspective that
have been an adjustment.

I would be curious to Tom's differences as well.

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

Joshua D. Drake wrote:

> Perhaps a more difficult problem is that there is no easy way to update
> a single file within a git repo. In cvs or svn, if I blow something up
> on a particular file and I just want to take a fresh look, I just rm;svn
> update.

Hmm, you should use "git revert" for that (same with SVN actually).

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Hi Joshua,

On 05/09/2009 12:22 AM, Joshua D. Drake wrote:
>> Obviously, an unchecked cvs diff would have produced the same garbage. Any
>> other problems?
> There are a number of conceptual differences. For example as a majority
> svn user, svn diff does not act the way git diff does. In that svn diff
> will only give me the difference within the current working directory.
> It will not go to the beginning of the tree and give me a diff.
git diff .

Although admittedly that takes some time getting used to.

> Perhaps a more difficult problem is that there is no easy way to update
> a single file within a git repo. In cvs or svn, if I blow something up
> on a particular file and I just want to take a fresh look, I just rm;svn
> update.
git checkout HEAD [--] your_file

Andres

Hi Alvaro,

On 05/09/2009 12:26 AM, Alvaro Herrera wrote:
>> Perhaps a more difficult problem is that there is no easy way to update
>> a single file within a git repo. In cvs or svn, if I blow something up
>> on a particular file and I just want to take a fresh look, I just rm;svn
>> update.
> Hmm, you should use "git revert" for that (same with SVN actually).
Uh. Unfortunately not. git revert is for reverting the effects of an
earlier commit, not a working copy difference.

Andres

Andres Freund wrote:
> Hi Alvaro,
>
> On 05/09/2009 12:26 AM, Alvaro Herrera wrote:
>>> Perhaps a more difficult problem is that there is no easy way to update
>>> a single file within a git repo. In cvs or svn, if I blow something up
>>> on a particular file and I just want to take a fresh look, I just rm;svn
>>> update.
>> Hmm, you should use "git revert" for that (same with SVN actually).
> Uh. Unfortunately not. git revert is for reverting the effects of an
> earlier commit, not a working copy difference.

Thanks for the clarification :-)

So how do you revert WC changes? At least I got the SVN part right --
which is not surprising because that's the one I actually use. Oh, and
monotone uses 'revert' for the WC meaning too (the other one does not
really make much sense to me, but so does git as a whole)

(You can't be serious that for reverting a WC file to the repository
state you use "git checkout"?)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Saturday 09 May 2009 01:41:20 Alvaro Herrera wrote:
> (You can't be serious that for reverting a WC file to the repository
> state you use "git checkout"?)

Why not? The purpose of the operation is to get a file from the repository.
It's not much different whether you do it the first or the second time.

On Fri, May 8, 2009 at 6:41 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Andres Freund wrote:
>> Hi Alvaro,
>>
>> On 05/09/2009 12:26 AM, Alvaro Herrera wrote:
>>>> Perhaps a more difficult problem is that there is no easy way to update
>>>> a single file within a git repo. In cvs or svn, if I blow something up
>>>> on a particular file and I just want to take a fresh look, I just rm;svn
>>>> update.
>>> Hmm, you should use "git revert" for that (same with SVN actually).
>> Uh. Unfortunately not. git revert is for reverting the effects of an
>> earlier commit, not a working copy difference.
>
> Thanks for the clarification :-)
>
> So how do you revert WC changes?  At least I got the SVN part right --
> which is not surprising because that's the one I actually use.  Oh, and
> monotone uses 'revert' for the WC meaning too (the other one does not
> really make much sense to me, but so does git as a whole)
>
> (You can't be serious that for reverting a WC file to the repository
> state you use "git checkout"?)

Yes, that's right. I found that a bit odd too, but it's really not
bad once you get used to it.

If you want to blow away ALL your changes, you can use "git reset
--hard". If you want to remove all the untracked files from your
working tree, you can use "git clean".

...Robert

On Fri, May 8, 2009 at 5:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> Yes I apologize for that. Git reacted differently than I expected to a
>> "git diff". I have since reposted a proper patch.
>
> mmm ... I've recently been forced into using git for another project,
> and I find myself mystified as to why anyone would want to use it.
> Seems like baroqueness and unexpected behaviors are all over the thing.

I had that same reaction at first. It is definitely different than
cvs or svn. The first time I tried to use it, I gave up. The second
time I tried to use it, I gave up. The third time I tried to use it,
I almost gave up. But now I love it. A couple of really nice things:

In CVS or SVN, there is no easy way (AFAIK) to get the entire history
of all changes to the repository. You can get the history of changes
to a FILE, but not the history of changes, period. In git, you just
run "git log". (Of course if you want to restrict the output to
changes that modified a certain file, you just do "git log filename".)

If you are trying to find the last time something related to mumble
was changed, you can run "git log -Smumble", and it shows you every
commit that adds or removes a line containing the string "mumble".
This is pretty useful when trying to familiarize yourself with the
history of a certain bit of code. There are also options to search by
regex, etc.

The branching and merging stuff is incredibly good and useful. It
takes a bit of getting used to the commands, but it is so much easier
than cvs or svn. Actually, svn isn't bad for MAKING branches (which
was what initially persuaded me to use it), but it @$# sucks for
merging them. It is just terrible. It may even be worse than CVS.
Don't get me wrong: I used CVS very happily for more than 10 years,
and it does what it does just fine, but git is so much more powerful
that it's not even funny. I can't get over how much faster I can do
things now that used to be a major headache.

...Robert

On May 8, 2009, at 4:00 PM, Peter Eisentraut wrote:

>> (You can't be serious that for reverting a WC file to the repository
>> state you use "git checkout"?)
>
> Why not? The purpose of the operation is to get a file from the
> repository.
> It's not much different whether you do it the first or the second
> time.

Yeah, this makes it difficult for me to remember, too. I'm constantly
asking how to do this on #git.

Best,

David

Joshua D. Drake wrote:
> Hello,
>
> Here is a diff of version_stamp.pl. It is not quite done as I can't
> actually get it to run. No matter what I do it doesn't appear to be able
> to open configure.in.
>
> If someone could help me figure out where I am being stupid I would
> appreciate it.
>
>

Maybe you aren't running it in the right directory (i.e. the directory
where configure.in exists)?

Anyway, I think what you want to achieve (without all the git crap) is
the attached.

cheers

andrew

Hi,

Le 8 mai 09 à 23:50, Tom Lane a écrit :
> mmm ... I've recently been forced into using git for another project,
> and I find myself mystified as to why anyone would want to use it.
> Seems like baroqueness and unexpected behaviors are all over the
> thing.

As a user of darcs I've been reacting in the same way for a long time,
and trying to avoid to have to try out git. It turns out that a
tutorial style video for an emacs mode for git made me change my mind
(what I dislike about git is its user interface):
http://vimeo.com/2871241

Maybe this would have some positive effect on your way to appreciate
git too? :)

Regards,
--
dim

On Fri, May 08, 2009 at 09:04:18PM -0400, Andrew Dunstan wrote:
>
>
> Joshua D. Drake wrote:
>> Hello,
>>
>> Here is a diff of version_stamp.pl. It is not quite done as I can't
>> actually get it to run. No matter what I do it doesn't appear to be able
>> to open configure.in.
>>
>> If someone could help me figure out where I am being stupid I would
>> appreciate it.
>
>
> Maybe you aren't running it in the right directory (i.e. the directory
> where configure.in exists)?
>
> Anyway, I think what you want to achieve (without all the git crap) is
> the attached.

Here's some git crap, but it makes all the .pl programs strict-clean.
Many are still horrendous, though.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David, I am sorry this didn't get applied, and the code has drifted too
much to apply it now. Would you be able to make a new patch to make our
Perl files strict?

---------------------------------------------------------------------------

David Fetter wrote:
> On Fri, May 08, 2009 at 09:04:18PM -0400, Andrew Dunstan wrote:
> >
> >
> > Joshua D. Drake wrote:
> >> Hello,
> >>
> >> Here is a diff of version_stamp.pl. It is not quite done as I can't
> >> actually get it to run. No matter what I do it doesn't appear to be able
> >> to open configure.in.
> >>
> >> If someone could help me figure out where I am being stupid I would
> >> appreciate it.
> >
> >
> > Maybe you aren't running it in the right directory (i.e. the directory
> > where configure.in exists)?
> >
> > Anyway, I think what you want to achieve (without all the git crap) is
> > the attached.
>
> Here's some git crap, but it makes all the .pl programs strict-clean.
> Many are still horrendous, though.
>
> Cheers,
> David.
> --
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate

[ Attachment, skipping... ]

>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

On Thu, Feb 25, 2010 at 05:39:10PM -0500, Bruce Momjian wrote:
>
> David, I am sorry this didn't get applied, and the code has drifted too
> much to apply it now. Would you be able to make a new patch to make our
> Perl files strict?

Please find updated patch attached. It passes strict, warnings, and
perlcritic -4

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david(at)fetter(dot)org> writes:
> -} elsif ($minor eq "devel") {
> - $dotneeded = 0;
> - $numericminor = 0;
> -} elsif ($minor =~ m/^alpha\d+$/) {
> - $dotneeded = 0;
> - $numericminor = 0;
> -} elsif ($minor =~ m/^beta\d+$/) {
> - $dotneeded = 0;
> - $numericminor = 0;
> -} elsif ($minor =~ m/^rc\d+$/) {
> +} elsif ($minor =~ m/
> + ^
> + (
> + devel |
> + alpha\d+ |
> + beta\d+ |
> + rc\d+
> + )
> + $/x) {

FWIW, I don't care for the above part of the patch. It doesn't seem to
me to improve readability one iota, if anything the reverse; and it
makes the logic less amenable to modification. If we wanted to make the
behavior at all different for alpha/beta/rc cases, we'd have to undo it
anyway.

regards, tom lane