latest 20 messages by Spark
+
[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