These are notes for using Mercurial. (They really don’t belong in the Java QRG section, but since I use Mercurial to get Java source files, it feels appropriate for me to include them here.)
|init||initializes a repository as a mercurial repository|
|status||gets the status of the repo|
|add –all||adds all the files|
|add sample.txt||adds a specific file to the repo|
|add *.md||add all files with an .md extension to the repo|
|add .||add all files of all extensions to the repo|
|commit -m “here’s my commit msg”||commit the current files to the repository|
|log||get a log of the commits|
|remote add origin https://github.com/your_repo||set the github repo destination to your repo|
|push -u origin master||push to your repo|
|pull origin master||get files from the repo|
|get diff HEAD||see the changes|
|rm ‘*.dita’||remove all the files with the .dita extension from the repository|
|merge||merge your local files with the latest working set|
|up||go to the working set (the latest changeset)|
|diff||see the differences between stuff|
|clone||clones a repository into a folder in the current directory. also sets up hg in this local repository. cd to /users/tjohnson/projects. Then
|up or update||updates the content to the latest working copy|
||this lets you know what the latest parent is. still not entirely sure what the parent means.|
||update to the latest working set|
||allows you to rollback to an earlier changeset|
||lets you know what heads you’re merging here.|
||makes it so an added file is no longer added.|
||opens a file so you can edit it (not HG specific)|
||opens a file in sublime so you can edit it.|
||shows ally he outgoing changes|
Basic flow in pushing content
- Make changes, and then go
hg commit -m "commit message"
- If there are problems in pushing the content, then you type
- If there are conflicts, type
- It will create a bunch of merges in the file. go through and sort it out first. remove all the »»» and «««<.
hg resolve --mark file.txt. this will mark the conflict as resolved.
- Save the file and type
hg commit -m "commit message".
hg push. Now there shouldn’t be any problems.
Basic flow in pulling content:
- Go to
hg pullto get the latest changeset.
hg updateto update to the latest working copy. (you can also do
hg pull -uto accomplish it all in one command.)
- If there are problems, you’re notified about them. do
- The files get merged and you have to go through and sort out the conflicts. remove all the »»» and «««<.
hg resolve --mark file.txtthis will mark the conflict as resolved.
hg commit -m "commit message"
If you’re asked if you want to put multiple heads in the same file, don’t do it. It messes things up.
- Everything is a changeset. when you commit it, that diff is a changeset.
- All that cloning does is take all the changesets and add them to your machine.
- changeset numbers are different per each box. the numbers are for your own info.
pullgrabs all the change sets.
- hg forget: after you delete a file, in order to tell Mercurial not to warn you that it’s missing, use the
Testing the multi-user scenario
Create a repository called remote:
hg mkdir remote cd remote hg init
Now clone the repository into 2 other repositories:
hg clone remote jp hg clone remote dm
Now open up several windows in iTerm: **Shell > Split Vertically **(do it twice)
In your other windows, cd to jp and cd to dm.
Now create a sample file and put it in remote. Make changes with one user and push. Pull from another user and make changes, etc. Works really well.
Clone a repository
cd to /users/tjohnson/projects hg clone <mercurial URL>
Add all files to a repository
hg add .
Commit the files
hg commit -m "your commit msg"
Get the logs
Push to the central repository
Create an HG repository
do this if you’re creating an HG repository locally:
Get the latest files
See list of changed files
See what changed in a specific file
hg diff file.txt
Update the working directory
Go forward or backwards in the directory
hg update -r 0
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.