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<[email protected]> 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
--
Sent via pgsql-committers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
