Think of commits in Mercurial or Git as snapshots of your project; functionally it’s like a full backup of everything as it was at that point in time. The source control system does some optimisations for the sake of disk space and speed, but functionally it tries to be indistinguishable from full backups. The only thing git or hg will save, however, is what you commit.
If you’re saving your project after each incremental change, Git won’t see that or save those incremental changes. When you commit, it will look at the last commit in the branch, figure out the difference between the file you are committing and the older version of the same file, and save those changes as one set of modifications.
I find the git index (“staging area”) quite useful and not particularly hard to understand. If I want the hg behaviour of commiting the whole repository without staging it first, I can do git commit -a.
I’m still figuring out what a remote is needed for if you’re not collaborating. Is it just for backup? Would creating your repository in a Dropbox folder (which I think gets saved both on your machine and in the cloud automatically) eliminate the need for that?
Regarding what various people have said about incremental changes vs. commits, I was reading this Git tutorial and trying to understand what was meant here: “Instead of committing all of the changes you’ve made since the last commit, the stage lets you group related changes into highly focused snapshots before actually committing it to the project history. This means you can make all sorts of edits to unrelated files, then go back and split them up into logical commits by adding related changes to the stage and commit them piece-by-piece. As in any revision control system, it’s important to create atomic commits so that it’s easy to track down bugs and revert changes with minimal impact on the rest of the project.”
This almost makes it sound like you can go into a file and divide up the changes in that file, if you want to. Is that the case with Git, or can you not split up changes within a single file?
While you can do that, usually it’s more common to use the git index to commit different files in different commits. Inform 7 projects are usually one monolithic source file, but for example, on a Raconteur project, I can make a bunch of changes to the game overall, then split the CSS changes into one commit, the changes to individual modules into other commits, and so on.
Many git installations also have “git gui” command which is a simple tool that allows you to pick up chunks or even select individual lines of changes for staging with mouse. This is a nice alternative to command line approach. Once you have changes staged, you can commit from the gui too. However cli (git add -i for full menu) has even the ability to edit what you are staging so when you have two independent changes on the same line you still can isolate them apart into different commits. I’m doing this all the time
I mean, if we’re being honest we all eventually end up finding monster commits with hundreds of lines of changes and only “MEDIOCRE” as a commit message, but when you use it with tender loving care git is a really powerful tool.
Thanks for the tip. I can open Git GUI (I can select it from a drop down menu in Git Extensions–the other menu options being Git bash and GitK) though I’m not sure if this is the same thing you are talking about. I haven’t figured out how to do anything with individual changes other than highlight them with the mouse.
cli=command line interface?
EDIT: I found instructions here for staging individual lines with Git GUI. I’ll have to experiment with it.
