+ [2016-10-22T15:44:59Z] Spark that being github.com/grit-engine/grit-engine
+ [2016-10-22T15:44:52Z] Spark Hi, is there a process whereby an inactive and empty user github.com/grit/ can be reclaimed by an established project under the same name?
+ [2016-06-03T18:33:27Z] Spark but i'll need to merge upstream changes somehow
+ [2016-06-03T18:33:13Z] Spark but i can also maintain it on bitbucket and have my fork mirrored on github, instead of the original
+ [2016-06-03T18:32:50Z] Spark i'd rather maintain my fork on github if possible, because i keep forgetting how to use the hg commandline tool
+ [2016-06-03T18:32:28Z] Spark what's the recommended way to sync from bitbucket hg to github?
+ [2016-06-03T01:06:55Z] Spark it doesn't have to be completely automatic
+ [2016-06-03T01:06:34Z] Spark and then keep that branch up to date and rebase my changes from it
+ [2016-06-03T01:06:22Z] Spark i think what i probably want is to have a branch that mirrors the original exactly, and then a branch with my forked changes
+ [2016-06-03T01:05:25Z] Spark hi, if I made a github repo by cloning a bitbucket mercurial repo, is it possible to then keep it synced?
+ [2016-04-09T16:57:27Z] Spark however hte first time since 2008
+ [2016-04-09T16:57:00Z] Spark this will be the 3rd time i've lost history for this project
+ [2016-04-09T16:56:20Z] Spark i'll probably just have to lose history
+ [2016-04-09T16:54:23Z] Spark Zarthus: forgot to tag you
+ [2016-04-09T16:50:22Z] Spark whereas in svn it stays server side and is less of a problem
+ [2016-04-09T16:50:12Z] Spark but generally if it's going to be a 100G repo then that's useless if you get all that every time you clone it
+ [2016-04-09T16:49:50Z] Spark somebody tried it and said it did not make any progress
+ [2016-04-09T16:24:37Z] Spark For people wondering what the context is: I'd like to move a large svn repository ~4G when checked out, 3000 commits, from sourceforge to github -- is that very large? The reason it's so big is that it has images and binaries that have been updated repeatedly, so presumably server side it's much bigger than that because only the server has all the history in svn (correct me if wrong).
+ [2016-04-09T16:22:04Z] Spark because files get moved around, i can't see how any algorithm can replay the state to keep the history with a constraint like that
+ [2016-04-09T16:21:47Z] Spark even if i want to keep only a complete subtree like /src or whatever