Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Several changes #76

wants to merge 5 commits into
Commits on Jun 14, 2010
  1. Made the update process of git do an explicit fetch+merge instead of a

    Simone Deponti committed Jun 14, 2010
    pull and then merge (which was not what we wanted, as pull IS
    fetch+merge). Not tested, so here be dragons, etc.
Commits on Jul 27, 2010
Commits on Jan 2, 2012
  1. Refactored a bit the threading code.

    simonedeponti committed Jan 2, 2012
    The system now doesn't seem to block that much.
Commits on Jan 3, 2012
  1. Coalesced locks and refactored git support.

    simonedeponti committed Jan 3, 2012
    The locks in common.py have been coalesced into one giant, re-entrant
    lock. This is because the spread out use of locks didn't quite ensure
    that a single thread never tried to acquire the same lock twice which,
    with a non re-entrant lock, means everything would die. Furthermore,
    having more than one lock just leads to confusion and possible
    deadlocking, while offering very little "overconcurrency" over the
    single lock approach.
    In git, the support for git 1.5 has been removed. Actually, I think it
    is still possible to support git 1.5 organically within a single
    class, as the only difference lies in how the remote branches are
    named (and git 1.6+ probably still support the old naming). The other
    thing I'm not sure git 1.5 supports is the -n switch on "remote show",
    but that's because it's quite hard for me to get access to git 1.5
    Also, the system will look in PATH for the executable, without
    launching too many Popens, and uses a fast matching method (looks at
    cached information on the remote instead of doing ls-remote, via the
    -n switch).