Prev: Add column if not exists (CINE)
Next: [HACKERS] need more ALTER TABLE guards for typed tables
From: Heikki Linnakangas on 1 Aug 2010 05:08
On 21/07/10 18:22, Robert Haas wrote:
> At the developer meeting, I promised to do the work of documenting how
> committers should use git. So here's a first version.
>
> http://wiki.postgresql.org/wiki/Committing_with_Git
>
> Note that while anyone is welcome to comment, I mostly care about
> whether the document is adequate for our existing committers, rather
> than whether someone who is not a committer thinks we should manage
> the project differently... that might be an interesting discussion,
> but we're theoretically making this switch in about a month, and
> getting agreement on changing our current workflow will take about a
> decade, so there is not time now to do the latter before we do the
> former. So I would ask everyone to consider postponing those
> discussions until after we've made the switch and ironed out the
> kinks. On the other hand, if you have technical corrections, or if
> you have suggestions on how to do the same things better (rather than
> suggestions on what to do differently), that would be greatly
> appreciated.

I'm a bit disappointed that the wiki page advises against
git-new-workdir - that's exactly what I was planning to use. It claims
there's data loss issues with that, does someone know the details? Is
there really a risk of data loss if multiple workdirs are used, in our
situation?

I'm planning to have only one local repository, with one workdir per
branch. When applying a patch to multiple branches, I could work
simultaneously on all branches, finish and commit the patches on all
branches, and finally do one "git push" to push all the changes to the
PostgreSQL repository in one go.

I'm working like that with the internal EDB repository right now, and
seems to work fine. I keep the master branch checked out in the "main"
workdir, within the repository, and for each backbranch there's an extra
workdir created with git-new-workdir. Though I've only been doing this
for a month or so - if there's issues I might not have noticed yet.

PS. I highly recommend always using "git push --dry-run" before the real
thing, to make sure you're not doing anything funny.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 4 Aug 2010 06:32
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> I'm a bit disappointed that the wiki page advises against git-new-workdir -
> that's exactly what I was planning to use. It claims there's data loss
> issues with that, does someone know the details? Is there really a risk of
> data loss if multiple workdirs are used, in our situation?

As I understand it, there is a risk of corruption if you ever do "git
gc" in the respository that the get-new-workdir was spawned from. See
also Daniel Farina's email, here:

http://archives.postgresql.org/pgsql-hackers/2010-07/msg01489.php

It's not easy for me to mentally verify that the way I work won't
cause problems with this approach, but you may feel differently, and
that's fine.

> PS. I highly recommend always using "git push --dry-run" before the real
> thing, to make sure you're not doing anything funny.

Ah, that sounds like a good idea.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 4 Aug 2010 09:34
On Wed, Aug 4, 2010 at 9:29 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Hmm, if I understand correctly, Daniel talks about data loss when using
> "alternates", if you e.g delete a branch and run "git gc" in the parent
> repository, because the child repository referring to the parent via the
> alternate reference can depend on objects in the parent repository that are
> no longer required by the parent repository itself.
>
> I guess that applies to multiple workdirs too, if you have staged but
> uncommitted changes in the staging area of a workdir. This message
> http://kerneltrap.org/mailarchive/git/2007/10/11/335637 agrees. Shawn O
> Pearce's last paragraph says:

You might want to edit your new section so that it refers to some of
the earlier material rather than duplicating it.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 4 Aug 2010 09:29
On 04/08/10 13:32, Robert Haas wrote:
> On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
> <heikki.linnakangas(a)enterprisedb.com> wrote:
>> I'm a bit disappointed that the wiki page advises against git-new-workdir -
>> that's exactly what I was planning to use. It claims there's data loss
>> issues with that, does someone know the details? Is there really a risk of
>> data loss if multiple workdirs are used, in our situation?
>
> As I understand it, there is a risk of corruption if you ever do "git
> gc" in the respository that the get-new-workdir was spawned from. See
> also Daniel Farina's email, here:
>
> http://archives.postgresql.org/pgsql-hackers/2010-07/msg01489.php
>
> It's not easy for me to mentally verify that the way I work won't
> cause problems with this approach, but you may feel differently, and
> that's fine.

Hmm, if I understand correctly, Daniel talks about data loss when using
"alternates", if you e.g delete a branch and run "git gc" in the parent
repository, because the child repository referring to the parent via the
alternate reference can depend on objects in the parent repository that
are no longer required by the parent repository itself.

I guess that applies to multiple workdirs too, if you have staged but
uncommitted changes in the staging area of a workdir. This message
http://kerneltrap.org/mailarchive/git/2007/10/11/335637 agrees. Shawn O
Pearce's last paragraph says:

> Heh. As you can see it has some "issues" with its use. Its a very
> powerful tool, but it does give you more than enough room to shoot
> yourself in the foot. Using it is like tieing a gun to your ankle,
> keeping it aimed at your big toe at all times, with a string tied
> to your wrist and the gun's trigger. Reach too far and *bam*.
> Which is why its still in contrib status.

All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but uncommitted
changes or other funny things. I can live with that gun tied to my ankle
;-).

I've added a section describing git-new-workdir the way I'm going to use it.

>> PS. I highly recommend always using "git push --dry-run" before the real
>> thing, to make sure you're not doing anything funny.
>
> Ah, that sounds like a good idea.

I added a note of that to the wiki too.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 4 Aug 2010 09:50


On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
>
> All those issues can be avoided if you only run "git gc" when all the
> working directories are in a clean state, with no staged but
> uncommitted changes or other funny things. I can live with that gun
> tied to my ankle ;-).


But to make sure of that I think you need to prevent git commands from
running gc automatically:

git config gc.auto 0

or possibly

git config --global gc.auto 0

And you'll need to make sure you run gc yourself from time to time.

cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Add column if not exists (CINE)
Next: [HACKERS] need more ALTER TABLE guards for typed tables