![]() The most spectacular example of this is the command “git am”, which as far as I can tell, is something Linus hacked up and forced into the main codebase to solve a problem he was having one night. The various options of “git reset” do completely different things. Specifying filenames completely changes the semantics of some commands (“git commit” ignores local, unstaged changes in foo.txt “git commit foo.txt” doesn’t). But the shortcut for “git branch” combined with “git checkout”? “git checkout -b”. Some “shortcuts” are graced with top level commands: “git pull” is exactly equivalent to “git fetch” followed by “git merge”. The command line syntax is completely arbitrary and inconsistent. Now Git: you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it. In fact, branches are tags, and files you already know about, so you really need to learn three new things. That’s pretty much everything you need to know. As a point of reference, consider Subversion: you have files, a working directory, a repository, versions, branches, and tags. The information model is complicated – and you need to know all of it. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. ![]() You would then have to take care not to push that changeset, though.Git is the source code version control system that is rapidly becoming the standard for open source projects. You could even just commit the changes, then update back to the parent and commit other work there, leaving the changes in a stubby anonymous branch - hg commit -m 'temporary branch' & hg up $(hg log -r 'parents(.)' -template '') (although it may be easier to do manually!). You could also use the queues extension, but that's using a sledgehammer to crack a nut. You can make this smoother by installing the shelve extension, the attic extension, or some other relative. The simplest thing is simply to use hg diff on the files to produce a patch describing them, which you keep somewhere safe, then hg patch -no-commit to reapply that patch when you want the changes back. ![]() If you are prepared to move the changes aside, you have another set of options. If you have a large number of files to exclude, or will be excluding them from many commits (eg for a permanent change to a local configuration file), look at the exclude extension. If they are already tracked, then you can specifically exclude them from commits with hg commit -exclude foo.txt. If the files are new, that's easy - just don't hg add them. If you keep them in the working copy, incoming changes will work fine, so you just need to avoid creating outgoing changes, and that means avoiding committing them. Which you choose depends on whether you want to have these changes available as you work. The first is to keep the changes in your working copy, but not push them, and the other is to put them aside, out of the working copy. So, for local changes that you don't yet want to share with other developers, you have two approaches. You refer to an "inability to merge with them" - if you have an uncommitted change to some file, and you pull and update a change to that file, Mercurial will start the merge process just as if you had committed it, then asked for a merge. I don't believe uncommitted changes are intrinsically a bad thing.
0 Comments
Leave a Reply. |