Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Typo fix.

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Dave Page <dpage(at)pgadmin(dot)org>, Robert Haas <rhaas(at)postgresql(dot)org>, Pg Committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Typo fix.
Date: 2012-01-13 17:29:44
Message-ID: 4F106A08.9010704@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-committers

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(at)hagander(dot)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



In response to

Responses

pgsql-committers by date

Next:From: Alvaro HerreraDate: 2012-01-13 18:46:10
Subject: Re: pgsql: Typo fix.
Previous:From: Simon RiggsDate: 2012-01-13 16:48:48
Subject: Re: pgsql: Typo fix.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group