Обсуждение: 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 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 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 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