pgsql: Ooops, no DATE_IS_NOBEGIN/DATE_IS_NOEND in 8.3 or 8.2 ...

On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Ooops, no DATE_IS_NOBEGIN/DATE_IS_NOEND in 8.3 or 8.2 ...

I heard the siren call of git cherry-pick, but should have lashed myself
to the mast.

Applying the same patch blindly to every branch can bite you no matter
how you move the patch around. Consider:

git cherry-pick -n master
# hack
git commit -a

Or:

git cherry-pick master
# check it, then, if needed, make and fold in modifications:
git commit -a --amend --date=now

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 12/28/2010 11:39 PM, Robert Haas wrote:

On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

Ooops, no DATE_IS_NOBEGIN/DATE_IS_NOEND in 8.3 or 8.2 ...

I heard the siren call of git cherry-pick, but should have lashed myself
to the mast.

Applying the same patch blindly to every branch can bite you no matter
how you move the patch around.

True. But imagining Tom as Odysseus is amusing :-)

cheers

andrew

Robert Haas <robertmhaas@gmail.com> writes:

On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I heard the siren call of git cherry-pick, but should have lashed myself
to the mast.

Applying the same patch blindly to every branch can bite you no matter
how you move the patch around.

Sure. But git cherry-pick encourages you to commit first and test
later, which is how come I ended up with a commit I couldn't undo.
Think I'll use -n in future.

regards, tom lane

On Tue, Dec 28, 2010 at 11:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I heard the siren call of git cherry-pick, but should have lashed myself
to the mast.

Applying the same patch blindly to every branch can bite you no matter
how you move the patch around.

Sure.  But git cherry-pick encourages you to commit first and test
later, which is how come I ended up with a commit I couldn't undo.
Think I'll use -n in future.

Well, you *can* undo it quite easily, as long as you haven't pushed
it. git reset --hard origin/master, git commit --amend, git rebase -i
origin/master, etc.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 12/28/2010 11:50 PM, Tom Lane wrote:

Robert Haas<robertmhaas@gmail.com> writes:

On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

I heard the siren call of git cherry-pick, but should have lashed myself
to the mast.

Applying the same patch blindly to every branch can bite you no matter
how you move the patch around.

Sure. But git cherry-pick encourages you to commit first and test
later, which is how come I ended up with a commit I couldn't undo.
Think I'll use -n in future.

Would not git reset have undone the faulty commit if necessary?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

On 12/28/2010 11:50 PM, Tom Lane wrote:

Think I'll use -n in future.

Would not git reset have undone the faulty commit if necessary?

Possibly. I looked at git revert, concluded it wouldn't do what
I wanted, and just went with an additional commit. Still learning
the tool ...

regards, tom lane

On Wed, Dec 29, 2010 at 12:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 12/28/2010 11:50 PM, Tom Lane wrote:

Think I'll use -n in future.

Would not git reset have undone the faulty commit if necessary?

Possibly.  I looked at git revert, concluded it wouldn't do what
I wanted, and just went with an additional commit.  Still learning
the tool ...

git revert would give you an extra commit. Andrew was speaking of git
reset, which can be used to undo a commit.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company