pgsql: Typo fix.
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(-)
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
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
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
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
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/
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
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
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
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
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
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