2009/5/12 Andreas Ericsson <ae@xxxxxx>: > I'd say: Hey, coders. If you want locking, we can write a small tool for > that. To make it a learning process too, that tool will be versioned by > git. We need a small (and stupid) server and a small (and stupid) client. > Locking will be advisory, so you can stick to it if you like, and you get > a nice reason to yell at whoever ignored your lock in case of conflicts. > > But that's just me, I guess. I've actually wanted such a tool as a sort > of "I'm working from home on *this* and *this*", but haven't been able > to muster the energy to work on it, especially since most of us where I > work are reasonably comfortable in the face of merge-conflicts. To indicate what's being worked on, both within and outside our traditional pessimistic locking strategy, we simply push lightweight tags to the central repo. It allows us to see who's got what locked (and since when), but it also allows us to do file-level three-way merges if necessary so we can keep long-running / speculative development up-to-date. The poor-man's rebase does the patch and moves the source tag along. Releasing the lock removes the tag. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html