Thread: pgsql: /home/peter/commit-msg
Log Message:
-----------
/home/peter/commit-msg
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/backend/tsearch:
wparser_def.c (r1.14.2.5 -> r1.14.2.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tsearch/wparser_def.c?r1=1.14.2.5&r2=1.14.2.6)
Peter Eisentraut wrote: > Log Message: > ----------- > /home/peter/commit-msg > > > er, what? cheers andrew
On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: > Peter Eisentraut wrote: >> Log Message: >> ----------- >> /home/peter/commit-msg >> > > er, what? I'm suspecting a misfired script somewhere. Cheers, David (oh, and what Andrew said) -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes: > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: >> Peter Eisentraut wrote: >>> /home/peter/commit-msg >> er, what? > I'm suspecting a misfired script somewhere. No doubt "cvs commit -m ~/commit-msg" instead of "cvs commit -F ~/commit-msg" ... I think I've made that mistake too. For the sake of the archives: it was the previously proposed fix for bug #5075, see http://archives.postgresql.org/pgsql-bugs/2009-11/msg00131.php regards, tom lane
On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: > On sön, 2009-11-15 at 17:09 -0500, Tom Lane wrote: > > David Fetter <david@fetter.org> writes: > > > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: > > >> Peter Eisentraut wrote: > > >>> /home/peter/commit-msg > > >> er, what? > > > I'm suspecting a misfired script somewhere. > > > > No doubt "cvs commit -m ~/commit-msg" instead of "cvs commit -F ~/commit-msg" > > ... I think I've made that mistake too. > > > > For the sake of the archives: it was the previously proposed fix for > > bug #5075, see > > http://archives.postgresql.org/pgsql-bugs/2009-11/msg00131.php > > Yeah, sorry guys. I fixed the CVS log message now. Strangely, the git repo still shows the old message. For the record, there's the new one: Make text search parser accept underscores in XML attributes (bug #5075) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Mon, Nov 16, 2009 at 08:29, David Fetter <david@fetter.org> wrote: > On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: >> On sön, 2009-11-15 at 17:09 -0500, Tom Lane wrote: >> > David Fetter <david@fetter.org> writes: >> > > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: >> > >> Peter Eisentraut wrote: >> > >>> /home/peter/commit-msg >> > >> er, what? >> > > I'm suspecting a misfired script somewhere. >> > >> > No doubt "cvs commit -m ~/commit-msg" instead of "cvs commit -F ~/commit-msg" >> > ... I think I've made that mistake too. >> > >> > For the sake of the archives: it was the previously proposed fix for >> > bug #5075, see >> > http://archives.postgresql.org/pgsql-bugs/2009-11/msg00131.php >> >> Yeah, sorry guys. I fixed the CVS log message now. > > Strangely, the git repo still shows the old message. For the record, > there's the new one: I don't find that strange at all. In git, the commit message is part of the commit, and thus the SHA1. If it changes, it would be a different commit. Which would change history and break the repositories of anybody pulling from it. So it's not only not strange, I'm very happy it didn't pull those changes and broke my repository :-) Now, if we want to "correct" that the way to do it is to rebuild the git mirror from scratch and have everybody start over, I think :-) While you're not supposed to change history in any RCS, git makes it a lot harder than cvs to do it... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Mon, Nov 16, 2009 at 08:29, David Fetter <david@fetter.org> wrote: >> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: >>> Yeah, sorry guys. I fixed the CVS log message now. >> Strangely, the git repo still shows the old message. For the record, >> there's the new one: > > I don't find that strange at all. > > In git, the commit message is part of the commit, and thus the SHA1. > > If it changes, it would be a different commit. Which would change > history and break the repositories of anybody pulling from it. > > So it's not only not strange, I'm very happy it didn't pull those > changes and broke my repository :-) Yeah, I'm glad it didn't do anything funny with the mirror. > Now, if we want to "correct" that the way to do it is to rebuild the > git mirror from scratch and have everybody start over, I think :-) > While you're not supposed to change history in any RCS, git makes it a > lot harder than cvs to do it... Nah, you'd only have to back out to the commit before the one that was broken. And actually git provides quite simple commands to do that, see git-reset for example. I forget how exactly the mirroring software works, but I presume it would then see that commit as a new one, as well as anything on top of it, and mirror them. Rewriting git history like that would mean that anyone who has pulled from the mirror since that commit happened would get an error the next time they try to pull/fetch again. But you can easily get over that by doing "git fetch --force". So we could rewrite the git history too, and I think it would be quite nice to have the right commit message there as well. But I don't care enough to volunteer to do the legwork. If we are going to do it, we should do it as soon as possible, while we're only a couple of commits ahead of that point. It's going to be more painful later on. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Mon, Nov 16, 2009 at 09:05, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Magnus Hagander wrote: >> On Mon, Nov 16, 2009 at 08:29, David Fetter <david@fetter.org> wrote: >>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: >>>> Yeah, sorry guys. I fixed the CVS log message now. >>> Strangely, the git repo still shows the old message. For the record, >>> there's the new one: >> >> I don't find that strange at all. >> >> In git, the commit message is part of the commit, and thus the SHA1. >> >> If it changes, it would be a different commit. Which would change >> history and break the repositories of anybody pulling from it. >> >> So it's not only not strange, I'm very happy it didn't pull those >> changes and broke my repository :-) > > Yeah, I'm glad it didn't do anything funny with the mirror. > >> Now, if we want to "correct" that the way to do it is to rebuild the >> git mirror from scratch and have everybody start over, I think :-) >> While you're not supposed to change history in any RCS, git makes it a >> lot harder than cvs to do it... > > Nah, you'd only have to back out to the commit before the one that was > broken. And actually git provides quite simple commands to do that, see > git-reset for example. I forget how exactly the mirroring software > works, but I presume it would then see that commit as a new one, as well > as anything on top of it, and mirror them. I would assume that yes, but I haven't tested it. > Rewriting git history like that would mean that anyone who has pulled > from the mirror since that commit happened would get an error the next > time they try to pull/fetch again. But you can easily get over that by > doing "git fetch --force". > > So we could rewrite the git history too, and I think it would be quite > nice to have the right commit message there as well. But I don't care > enough to volunteer to do the legwork. If we are going to do it, we > should do it as soon as possible, while we're only a couple of commits > ahead of that point. It's going to be more painful later on. Yeah. Right now, that commit is actually the top, so it would be just one. I was about to do it right now, then I realized that it hits backbranches as well so it's not quite so easy. So I won't do it now - I have to leave for JPUG pretty soon, and I don't want to risk leaving us with an inconsistent git mirror if things go wrong. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Heikki Linnakangas wrote: > So we could rewrite the git history too, and I think it would be quite > nice to have the right commit message there as well. But I don't care > enough to volunteer to do the legwork. If we are going to do it, we > should do it as soon as possible, while we're only a couple of commits > ahead of that point. It's going to be more painful later on. We had a little chat with Magnus, and decided to stop the cron job that updates the git mirror. The commit with wrong commit message is currently the latest commit, so it'll be quite painless to back it out now before more commits are mirrored. However, Magnus is just getting on a plane, so he doesn't want to back out the commit right now because he wouldn't have time to fix it if something goes wrong. Stopping the mirror buys us time to do it later and test it properly, and if we decide to leave it as it is in the end, we can just re-enable the cron job. In any case, we'll have the mirroring re-enabled in a couple of days. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On sön, 2009-11-15 at 17:09 -0500, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: > >> Peter Eisentraut wrote: > >>> /home/peter/commit-msg > >> er, what? > > I'm suspecting a misfired script somewhere. > > No doubt "cvs commit -m ~/commit-msg" instead of "cvs commit -F ~/commit-msg" > ... I think I've made that mistake too. > > For the sake of the archives: it was the previously proposed fix for > bug #5075, see > http://archives.postgresql.org/pgsql-bugs/2009-11/msg00131.php Yeah, sorry guys. I fixed the CVS log message now.
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Magnus Hagander wrote:
>> On Mon, Nov 16, 2009 at 08:29, David Fetter <david@fetter.org> wrote:
>>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote:
>>>> Yeah, sorry guys. I fixed the CVS log message now.
>> So it's not only not strange, I'm very happy it didn't pull those
>> changes and broke my repository :-)
> Yeah, I'm glad it didn't do anything funny with the mirror.
I think we should have a policy of NO manual changes to the CVS
repository files. At least not without careful discussion beforehand.
The lack of a commit message for this one small patch was absolutely
not worth taking any risks to fix.
regards, tom lane
On mån, 2009-11-16 at 10:05 -0500, Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > > Magnus Hagander wrote: > >> On Mon, Nov 16, 2009 at 08:29, David Fetter <david@fetter.org> wrote: > >>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: > >>>> Yeah, sorry guys. I fixed the CVS log message now. > > >> So it's not only not strange, I'm very happy it didn't pull those > >> changes and broke my repository :-) > > > Yeah, I'm glad it didn't do anything funny with the mirror. > > I think we should have a policy of NO manual changes to the CVS > repository files. At least not without careful discussion beforehand. I used cvs admin.
2009/11/16 Peter Eisentraut <peter_e@gmx.net>: > On mån, 2009-11-16 at 10:05 -0500, Tom Lane wrote: >> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> > Magnus Hagander wrote: >> >> On Mon, Nov 16, 2009 at 08:29, David Fetter <david@fetter.org> wrote: >> >>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: >> >>>> Yeah, sorry guys. I fixed the CVS log message now. >> >> >> So it's not only not strange, I'm very happy it didn't pull those >> >> changes and broke my repository :-) >> >> > Yeah, I'm glad it didn't do anything funny with the mirror. >> >> I think we should have a policy of NO manual changes to the CVS >> repository files. At least not without careful discussion beforehand. > > I used cvs admin. I've cleaned up the git repo, and re-enabled the mirror script. From what I can tell it works fine. In theory you will need to use force mode if you pulled the broken commit that was removed (the one with the wrong message), but it seems this is not necessarily required. As for the future, please avoid doing any "cvs admin" activity if possible, and if it's done let's specifically coordinate with the git mirror script, to make sure things work smoothly. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, 20 Nov 2009, Magnus Hagander wrote: > I've cleaned up the git repo, and re-enabled the mirror script. From > what I can tell it works fine. In theory you will need to use force > mode if you pulled the broken commit that was removed (the one with > the wrong message), but it seems this is not necessarily required. Just to clarify here, what was the point of stopping the sync script? Unless the sync was stopped prior to the modified commit there's no difference for an end user here. If they pulled the modified commit they've got a semi-broken repo. All that's happened is that they weren't able to pull newer updates as well which seems like a net loss. Kris Jurka
Kris Jurka wrote: > On Fri, 20 Nov 2009, Magnus Hagander wrote: > >> I've cleaned up the git repo, and re-enabled the mirror script. From >> what I can tell it works fine. In theory you will need to use force >> mode if you pulled the broken commit that was removed (the one with >> the wrong message), but it seems this is not necessarily required. > > Just to clarify here, what was the point of stopping the sync script? > Unless the sync was stopped prior to the modified commit there's no > difference for an end user here. If they pulled the modified commit > they've got a semi-broken repo. All that's happened is that they > weren't able to pull newer updates as well which seems like a net loss. We figured it's easier to backtrack if there's no more commits on top of the modified one. Not sure how true it really was. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Fri, Nov 20, 2009 at 2:44 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Kris Jurka wrote: >> On Fri, 20 Nov 2009, Magnus Hagander wrote: >> >>> I've cleaned up the git repo, and re-enabled the mirror script. From >>> what I can tell it works fine. In theory you will need to use force >>> mode if you pulled the broken commit that was removed (the one with >>> the wrong message), but it seems this is not necessarily required. >> >> Just to clarify here, what was the point of stopping the sync script? >> Unless the sync was stopped prior to the modified commit there's no >> difference for an end user here. If they pulled the modified commit >> they've got a semi-broken repo. All that's happened is that they >> weren't able to pull newer updates as well which seems like a net loss. > > We figured it's easier to backtrack if there's no more commits on top of > the modified one. Not sure how true it really was. FWIW, I had good luck with "git rebase origin/master". ...Robert
2009/11/20 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>: > Kris Jurka wrote: >> On Fri, 20 Nov 2009, Magnus Hagander wrote: >> >>> I've cleaned up the git repo, and re-enabled the mirror script. From >>> what I can tell it works fine. In theory you will need to use force >>> mode if you pulled the broken commit that was removed (the one with >>> the wrong message), but it seems this is not necessarily required. >> >> Just to clarify here, what was the point of stopping the sync script? >> Unless the sync was stopped prior to the modified commit there's no >> difference for an end user here. If they pulled the modified commit >> they've got a semi-broken repo. All that's happened is that they >> weren't able to pull newer updates as well which seems like a net loss. > > We figured it's easier to backtrack if there's no more commits on top of > the modified one. Not sure how true it really was. It made the work a bit easier, but it would've worked if it kept running as well. But we didn't know it at the time. Actually, it would've been more likely to cause conflicts for people I think, since we would still have had to revert everything back to the commit before the broken one anyway, and it would then affect more files for those who had pulled a broken version. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/