Thread: pgsql: Typo fix.

pgsql: Typo fix.

From
Robert Haas
Date:
Typo fix.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/4d0b11a0ca347e5b0304004625b7eb6752e32ee7

Modified Files
--------------
src/backend/replication/walreceiver.c |    2 +-
1 files changed, 1 insertions(+), 1 deletions(-)


Re: pgsql: Typo fix.

From
Simon Riggs
Date:
On Fri, Jan 13, 2012 at 1:22 PM, Robert Haas <rhaas@postgresql.org> wrote:

> Typo fix.

Hmm, how strange. I fixed that bug immediately before commit, so must
have skipped a step while committing.

Thanks.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: pgsql: Typo fix.

From
Dave Page
Date:
On Fri, Jan 13, 2012 at 1:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, Jan 13, 2012 at 1:22 PM, Robert Haas <rhaas@postgresql.org> wrote:
>
>> Typo fix.
>
> Hmm, how strange. I fixed that bug immediately before commit, so must
> have skipped a step while committing.

If you modify a file after git-adding it, you have to re-add it before
committing. Possible cause?


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: pgsql: Typo fix.

From
Dave Page
Date:
On Fri, Jan 13, 2012 at 2:03 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, Jan 13, 2012 at 1:39 PM, Dave Page <dpage@pgadmin.org> wrote:
>> On Fri, Jan 13, 2012 at 1:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Fri, Jan 13, 2012 at 1:22 PM, Robert Haas <rhaas@postgresql.org> wrote:
>>>
>>>> Typo fix.
>>>
>>> Hmm, how strange. I fixed that bug immediately before commit, so must
>>> have skipped a step while committing.
>>
>> If you modify a file after git-adding it, you have to re-add it before
>> committing. Possible cause?
>
> No, dumber than that.
>
> I compiled a new version, just skipped the bit where I updated the new
> patch version, so the old one just got applied.
>
> I keep separate dev and write repositories and use patches to move
> between them. Which gives me less chance of committing dev code
> accidentally (like I just did). Is there a better way?

I suspect the git purists will suggest using a private branch to
develop in and then merging (and squashing) that into the master
branch to be pushed. I do that for some projects, and a similar
workflow to yours for others. Git gives you 20 ways to do anything
though, so I'm sure there are other options.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: pgsql: Typo fix.

From
Simon Riggs
Date:
On Fri, Jan 13, 2012 at 1:39 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Fri, Jan 13, 2012 at 1:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Fri, Jan 13, 2012 at 1:22 PM, Robert Haas <rhaas@postgresql.org> wrote:
>>
>>> Typo fix.
>>
>> Hmm, how strange. I fixed that bug immediately before commit, so must
>> have skipped a step while committing.
>
> If you modify a file after git-adding it, you have to re-add it before
> committing. Possible cause?

No, dumber than that.

I compiled a new version, just skipped the bit where I updated the new
patch version, so the old one just got applied.

I keep separate dev and write repositories and use patches to move
between them. Which gives me less chance of committing dev code
accidentally (like I just did). Is there a better way?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: pgsql: Typo fix.

From
Magnus Hagander
Date:
On Fri, Jan 13, 2012 at 15:03, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, Jan 13, 2012 at 1:39 PM, Dave Page <dpage@pgadmin.org> wrote:
>> On Fri, Jan 13, 2012 at 1:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Fri, Jan 13, 2012 at 1:22 PM, Robert Haas <rhaas@postgresql.org> wrote:
>>>
>>>> Typo fix.
>>>
>>> Hmm, how strange. I fixed that bug immediately before commit, so must
>>> have skipped a step while committing.
>>
>> If you modify a file after git-adding it, you have to re-add it before
>> committing. Possible cause?
>
> No, dumber than that.
>
> I compiled a new version, just skipped the bit where I updated the new
> patch version, so the old one just got applied.
>
> I keep separate dev and write repositories and use patches to move
> between them. Which gives me less chance of committing dev code
> accidentally (like I just did). Is there a better way?

Just FWIW, I use a separate development repository as well. But I have
it added as a remote from the "commit repository", and thus just do a
"git merge --squash" instead of manually moving them with "patch".

But I am very much a fan of keeping the repos separate for just that
reason - don't want to accidentally commit dev code.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: pgsql: Typo fix.

From
Simon Riggs
Date:
On Fri, Jan 13, 2012 at 2:26 PM, Magnus Hagander <magnus@hagander.net> wrote:

> Just FWIW, I use a separate development repository as well. But I have
> it added as a remote from the "commit repository", and thus just do a
> "git merge --squash" instead of manually moving them with "patch".
>
> But I am very much a fan of keeping the repos separate for just that
> reason - don't want to accidentally commit dev code.

OK thanks.

My patch foo seems occasionally faulty, but git merge --disaster is
something I'm happy to avoid. I'll work on my hand grenade juggling
skills before I do that.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: pgsql: Typo fix.

From
Andrew Dunstan
Date:

On 01/13/2012 10:22 AM, Simon Riggs wrote:
> On Fri, Jan 13, 2012 at 2:26 PM, Magnus Hagander<magnus@hagander.net>  wrote:
>
>> Just FWIW, I use a separate development repository as well. But I have
>> it added as a remote from the "commit repository", and thus just do a
>> "git merge --squash" instead of manually moving them with "patch".
>>
>> But I am very much a fan of keeping the repos separate for just that
>> reason - don't want to accidentally commit dev code.
> OK thanks.
>
> My patch foo seems occasionally faulty, but git merge --disaster is
> something I'm happy to avoid. I'll work on my hand grenade juggling
> skills before I do that.


How you work is up to you, but "git merge --squash" is pretty safe,
since it doesn't actually commit anything.

cheers

andrew

Re: pgsql: Typo fix.

From
Alvaro Herrera
Date:
Excerpts from Andrew Dunstan's message of vie ene 13 12:49:58 -0300 2012:
>
> On 01/13/2012 10:22 AM, Simon Riggs wrote:
> > On Fri, Jan 13, 2012 at 2:26 PM, Magnus Hagander<magnus@hagander.net>  wrote:
> >
> >> Just FWIW, I use a separate development repository as well. But I have
> >> it added as a remote from the "commit repository", and thus just do a
> >> "git merge --squash" instead of manually moving them with "patch".
> >>
> >> But I am very much a fan of keeping the repos separate for just that
> >> reason - don't want to accidentally commit dev code.
> > OK thanks.
> >
> > My patch foo seems occasionally faulty, but git merge --disaster is
> > something I'm happy to avoid. I'll work on my hand grenade juggling
> > skills before I do that.
>
>
> How you work is up to you, but "git merge --squash" is pretty safe,
> since it doesn't actually commit anything.

And if things go wrong you can always do git merge --abort.

I, too, used to be scared of some of the options that git gives us, but
after experimentation I found some of them to be hugely useful and safe
enough that I now very rarely run use patches anymore.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: pgsql: Typo fix.

From
Simon Riggs
Date:
On Fri, Jan 13, 2012 at 4:05 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

>> How you work is up to you, but "git merge --squash" is pretty safe,
>> since it doesn't actually commit anything.
>
> And if things go wrong you can always do git merge --abort.
>
> I, too, used to be scared of some of the options that git gives us, but
> after experimentation I found some of them to be hugely useful and safe
> enough that I now very rarely run use patches anymore.

Gets better and better - very positive. OK, will give it a try. Thanks guys.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: pgsql: Typo fix.

From
Andrew Dunstan
Date:

On 01/13/2012 11:05 AM, Alvaro Herrera wrote:
> Excerpts from Andrew Dunstan's message of vie ene 13 12:49:58 -0300 2012:
>> On 01/13/2012 10:22 AM, Simon Riggs wrote:
>>> On Fri, Jan 13, 2012 at 2:26 PM, Magnus Hagander<magnus@hagander.net>   wrote:
>>>
>>>> Just FWIW, I use a separate development repository as well. But I have
>>>> it added as a remote from the "commit repository", and thus just do a
>>>> "git merge --squash" instead of manually moving them with "patch".
>>>>
>>>> But I am very much a fan of keeping the repos separate for just that
>>>> reason - don't want to accidentally commit dev code.
>>> OK thanks.
>>>
>>> My patch foo seems occasionally faulty, but git merge --disaster is
>>> something I'm happy to avoid. I'll work on my hand grenade juggling
>>> skills before I do that.
>>
>> How you work is up to you, but "git merge --squash" is pretty safe,
>> since it doesn't actually commit anything.
> And if things go wrong you can always do git merge --abort.
>
> I, too, used to be scared of some of the options that git gives us, but
> after experimentation I found some of them to be hugely useful and safe
> enough that I now very rarely run use patches anymore.

Yeah. Just note this from the docs:

    The third syntax ("git merge --abort") can only be run after the
    merge has resulted in conflicts. git merge --abort will abort the
    merge process and try to reconstruct the
    pre-merge state. However, if there were uncommitted changes when the
    merge started (and especially if those changes were further modified
    after the merge was started), git merge
    --abort will in some cases be unable to reconstruct the original
    (pre-merge) changes. Therefore:

    Warning: Running git merge with uncommitted changes is discouraged:
    while possible, it leaves you in a state that is hard to back out of
    in the case of a conflict.

Of course, if you aren't doing dev work on the tree in question that
shouldn't apply, presumably.

cheers

andrew



Re: pgsql: Typo fix.

From
Alvaro Herrera
Date:
Excerpts from Andrew Dunstan's message of vie ene 13 14:29:44 -0300 2012:

> Yeah. Just note this from the docs:
>
>     The third syntax ("git merge --abort") can only be run after the
>     merge has resulted in conflicts. git merge --abort will abort the
>     merge process and try to reconstruct the
>     pre-merge state. However, if there were uncommitted changes when the
>     merge started (and especially if those changes were further modified
>     after the merge was started), git merge
>     --abort will in some cases be unable to reconstruct the original
>     (pre-merge) changes.

Hm.  Whenever I find myself trying to merge something in a tree that
also has uncommitted changes (which is not very often), what I do is
"git stash" to save my work elsewhere and then run the git merge.  That
way, if things go wrong (which is also not very often), I can just abort
the merge and pop the patch from the stash, and I'm right back where I
started.  Otherwise, I pop my patch from the stash anyway and any merges
are handled by the same merge mechanism, so I can also roll that back if
things don't turn the way I initially wanted.

So while you can certainly screw up and lose work, it's also true that
you have all the tools not to.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support