On 04/08/10 13:32, Robert Haas wrote:
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
<heikki.linnakan...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
