ENIGMA Development Environment

I have gone too long without knowing this.

We're pretty much all in agreement with regards to the jars. I'm not sure about wgetting them from the makefile though - it's not that simple. The jars update occasionally - maybe once every 5-10 revisions. This means that we might not want to fetch them every time the user invokes make, because that would add an additional download time that usually just results in the same jars. We obviously don't want to do it as a 1-time thing because sometimes the updates are critical. We'd probably want some sort of intermediary to determine if the jars should be updated. Fetch some small information that determines the latest version, and compares it to the user's current version.

wget lgm.md5
if md5sum -c --quiet lgm.md5; then
  wget lgm*.jar
fiFor the Linux version, anyway. The Linux version should be managed via the makefile, whereas the Windows version of LGM should just update itself.
(windows/linux "version" meaning when used on said platforms)

I don't understand why Mercurial would even be brought up at all. Mercurial is worse with storing any kind of file (as size is concerned), and switching to it would be extremely counter-productive.

I worded that terribly, but both of you pretty much understood what I meant.

For the record, I fixed the dependencies for the Install#Linux page. :V

Random addition to the guide: git stash "stashes" existing changes whereas git stash pop will apply stashed changes. You can do git stash drop to just delete the stashed changes without applying them or git stash apply to apply stashed changes without dropping them. Stashes are stack-based, meaning that you can push several stashes onto the stack and pop them in a FILO (first-in, last-out) manner.

Also, fix the teletype tag.

Also, random thing that I found out the hard way:

If you're just interested in getting the latest revision (no version control), you can run:
git clone git://github.com/enigma-dev/enigma-dev.git --depth 1This will essentially download an unversioned copy of the latest revision.

This will prevent you from downloading all of the commits, which would be pretty big. It has a downside, however, of preventing you from pushing commits to the master repo.

Soo how exactly committing changes will work? In SVN it was extremely easy.. I suspect it will be as easy in GIT too? For example, I am on Win and want to have a GUI program (its just nicer) to commit a change to the repository. What steps would I use?

TortoiseGit is designed like TortoiseSVN with a very similar interface, intended for git instead. I don't quite know how either works, but I'll explain the main difference between git's committing and SVN's. Git has more options, but you can still commit in what's mostly the same way as SVN.

SVN commits are centralised, meaning that you have to send the commits to the central server for them to count. SVN only has one way of committing: you can add files that haven't yet been versioned (which will then make them versioned) and then commit, which will commit all modified or newly versioned files.

Git operates on a series of local repositories. This means that with Git, you "clone" the source repository, mess with it however that you want, and then push all of your changes to the destination repository. Through this process, you can make as many commits as you want, amend your commits, and even uncommit what you've done. However, once you move the changes to the destination repository, you're pretty much stuck with those commits. If you uncommit or amend things that are already on the destination repository, you'll have a hard time getting the repository to actually push new changes, because the changes don't match.

Git commits operate as staged and unstaged changes; essentially, anything that you've changed but haven't "staged" won't actually be committed. For example, if I modifed file1 and file2, which are versioned, adding a new commit won't commit those changes that I've made unless I explicitly ask for it (that's SVN's behaviour; you can still do this if you want). You also have to add new files, like SVN. Note that if you modify or delete a file after you stage it, those changes won't be applied until you stage it again. Once you commit something, you have to send it to the destination repository for it to actually be "committed" to the overall repository.

I'm assuming that things like TortoiseSVN and TortoiseGit already support a mechanism for "commit all," which will essentially just stage everything, commit, and push to the master repo, with a given commit message. Git largely replicates the functionality of SVN, although, it has a lot more features and operates slightly differently. It's also a lot faster and compresses things, making it easier and faster to pull from the remote repos.