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

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.

Branch
------
REL8_2_STABLE

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=2892fd5dea8ceb871d590bd60e70759596bb0bd6

Modified Files
--------------
src/backend/utils/adt/date.c | 15 ++++-----------
1 files changed, 4 insertions(+), 11 deletions(-)

On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
> On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)com> writes:
>> On Tue, Dec 28, 2010 at 11:02 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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(at)dunslane(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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