According to gjhiggins, it is a ported version of Litecoin with the latest updates (OpenSSL-fix etc.). We would have to ask him for details. Btw: you can then change back the coin-icon to the original one immediately as you like, since the other one is only a suggestion by Graham and he already stated, that he is out of the project, regarding active work on the code. He just wanted to provide a good new starting point for the community, after deaconboogie seemed to be so unreliable.
Precisely so.
There has been an unfortunate tendency for (forked/cloned) altcoins to be released with a code repository that (for some unfathomable reason) discards all the prior commit history, i.e. all the sequential detailed changes made to the parent coin, back from its inception right up to the point when it is forked to create the new altcoin. One extremely important consequence of this decision to excise the commit history is that it effectively prevents the newly-forked code from benefiting from any enhancements or bug fixes made to the parent after it was forked.
With “normal” git (revision control) practice, you create a fork of the original repository code. The technically accurate term is “fork” but the actual command borrows misleadingly and uselessly from genetics:
git clone You can then work completely separately on the forked code (say, making a few improvements or correcting a typo). At the end of the effort, you have a complete copy of the original, plus your changes. Assuming you have write access to the git repository from which you forked the code, you can simply commit the lot to the repos and that's the job done. Typically, unless you're a member of the development team, you won't have write access to a repository, instead you can submit a “pull request” to the repos admin, indicating that you have made specific changes. If your PR is acceptable, git allows the devs to integrate it very, very simply by merging your acceptably-changed copy of the code into the master.
But what happens if the original repos content is changed while you're still working? Your copy is now out of date and your PR will be rejected. The standard means of keeping your working copy up to date with changes to the master repository is to pull the changes from the repos and merge them into your copy with
git pull; git merge.
This is exactly how it could work with, say, Dogecoin and Mooncoin (the latter being a fork of the former). Bugs discovered and fixed in the parent Dogecoin repos could be merged into the Mooncoin code, enhancements and improvements to the Dogecoin code could be propagated to the Mooncoin code fairly simply (with thanks and due consideration) by merging. So, releasing a coin with a repos that cannot be used to merge bugfixes and improvements from the parent coin is a seriously retrograde step and will create a strong reliance on a capable dev who can migrate desirable changes in the Dogecoin code to the Mooncoin code.
I'll just vary the binding in the above para:
This is exactly how it could work with, say, Litecoin and Mooncoin (the latter being an indirect fork of the former). Bugs discovered and fixed in the parent Litecoin repos could be merged into the Mooncoin code, enhancements and improvements to the Litecoin code could be propagated to the Mooncoin code fairly simply (with thanks and due consideration) by merging. So, releasing a coin with a repos that cannot be used to merge bugfixes and improvements from the parent coin is a seriously retrograde step and will create a strong reliance on a capable dev who can migrate desirable changes in the Litecoin code to the Mooncoin code.
Mooncoin was launched as a fork of Litecoin 0.6.3 (as was Dogecoin). In late Feb, the extant Mooncoin 0.6.3 repos was overwritten completely with an
upgrade of Mooncoin code to match code in the Litecoin 0.8.6 repos.
I took this code-dump and integrated it back in to a fork of Litecoin 0.8.6 with a full commit history:
https://github.com/mooncoin-project/mooncoin-landann/commits/mooncoin?page=2The commit history now records in faithful detail, step-by-step, the process of going from recent Litecoin to latest Mooncoin and allows Litecoin upgrades (e.g. 0.8.6 -> 0.8.7) to be straightforwardly merged in to the Mooncoin code.
If Mooncoin follows Dogecoin to Bitcoin 0.9.2 (I strongly recommend this), then the above code is irrelevant, it all needs to be done again because there is no straightforward merge path from Litecoin 0.8.x to Bitcoin 0.9.X. However, the 0.8.6 commit history contains all the details of the path that was trodden previously.
I considered that to be the most effective contribution I could achieve without actually supplanting the official dev.
Cheers
Graham
... give me some time until weekend 
