<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 7:48 PM, Sean Farley <span dir="ltr"><<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":17v">Huh? gitifyhg should only be pulling the new changesets (isn't it<br>
keeping some kind of hash mapping around?).</div></blockquote><div><br></div><div style>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":17v"> Namespacing is completely<br>
unrelated to this, and IMO, unnecessary. For something as easy as this<br>
clean-up, all you need is one bookmark. </div></blockquote><div><br></div><div style>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":17v">If you want to get fancy, then<br>
you could clean-up history and whatnot but as I mentioned before,<br>
Bitbucket doesn't allow it. You could, of course, host your own server<br>
(ala Rhodecode) or, you know, quit your bitching and shoehorning<br>
unneeded concepts (namespaces, in this case).<br>
<br>
Your comment about a perpetually unstable Python API is a strawman. You<br>
must be using private functions and not the command server / API.</div></blockquote></div><br><br></div></div>