Jed Brown writes: > On Tue, Mar 5, 2013 at 7:48 PM, Sean Farley <sean at mcs.anl.gov> wrote: > >> Huh? gitifyhg should only be pulling the new changesets (isn't it >> keeping some kind of hash mapping around?). >> > > Gitifyhg keeps a separate hg clone per remote because we could not find a > reliable way to keep branches and bookmarks distinct. I would much prefer > it to use one hg repo that can pull quickly from any new place, but we > would need to be able to _guarantee_ that there were never collisions and > that no operations moved existing bookmarks. Maybe the extension you > mentioned will be able to support this at some point? Will it be able to > update named branches for different remotes without a race? (I don't know > if you can commit on one named branch (in a namespace) while writing the > unnamespaced branch name into the commit.)
And this is why I think git makes things more complicated than need be. Also, cantankerous but I digress. >> Namespacing is completely >> unrelated to this, and IMO, unnecessary. For something as easy as this >> clean-up, all you need is one bookmark. >> > > As I mentioned before, bookmarks in hg are much more in-your-face than git > branches. Up until now, we have not allowed multiple heads in any PETSc > repositories. Can we do it without confusing people? I disagree about them being in your face. I think you're making this workflow more complicated than need be. As for having multiple heads, I wouldn't recommend that workflow for this group just yet. The main drawback is Bitbucket not allowing non-publishing repos in case anyone screws something up (which will happen). Just use the pull-request model for now. This will already allow a more flexible workflow and will do it in an incremental step (as opposed to forcing advanced concepts and 'gotchas' on *everyone*).
