Archive for the ‘Git’ tag
Update: I recovered my lost commit by following the directions here. In addition, I had to create a branch from this commit using
chekcout -b. I then switch to the
master branch and merged the temporary branch into
It has been
written posted that
git revert is not the same as
svn revert. That’s true.
However, there have been suggestions that the equivalent is
git reset --hard commit. I just did this. It isn’t good. Luckily, I didn’t lose
muchany data. However, doing a
--hard means that you reset the index back in time, too–not just your working copy.
I’ll admit that I don’t understand git very well. I’m not entirely sure (now that I’ve gone back in time) how to bring myself back to the future.
git reset means that you want to get rid of changes in your repository: not merely go back in time, see what things looked like, and move forward in time.
Anyway, a safer thing (for me to have done) would be
git checkout commit.
The git manual specifically says:
Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since commit are lost.
Wonder if I’m too feeble to be MacGyver and need a James Bond. On the other hand, now that I’ve learned this lesson, maybe I’m better off sticking here.
I’m personally using Git to version-control my WikidPad files. However, Mercurial (and especially TortoiseHg) is equally well suited for this function. In many respects, Mercurial is simpler to use than Git. The only shortcoming I had with Mercurial is that there’s no managed branches; to branch, you create an independent copy of the whole repository (clone it).
Nonetheless, for most people, Mercurial will not only suffice but give quicker rewards than Git.
I don’t use Subversion for this purpose, because subversion has a centralized approach which requires a repository, separate from a working copy. Importing, merging, branching, etc., with subversion is a bit of a hassle. This “hassle”, of course, is purely personal taste; others will (strongly) disagree. In fact, for many other purposes, I strongly prefer Subversion to Mercurial/Git/etc.
By the time you’re done with the following steps, you should be able to:
- Place a WikidPad Wiki under version control
- Commit changes as files change
- Revert to prior versions Read the rest of this entry »
I personally like the “Original SQLite” format for storage. This internal database has the following properties:
The data for your wiki is stored in plain text under the data
directory of the directory your Wiki config is stored in. There is one
file per wiki word. The database to index the wiki is stored in the
Which is great, because I get all the features of SQLite search/indexing, but all my pages are in a text format.
The great thing about this setup is that I can use version-control to keep them in sync. I originally thought about using SubVersion. However, I decided to go with a distributed version control system instead. I took a hard look at both Mercurial and Git. I decided on Git since it does implicit renames rather than explicit renames. This means that I don’t have to write any hooks in WikidPad for when there is a rename/copy of a page. Of course, I could do without this feature in Mercurial, and it would still work. It’s just nice that Git does provide the benefit of diff-based storage without the need for explicit copies/renames/moves.
So, I keep two WikidPad notebooks going: a Work one, and a Personal one. The Personal one is on all the computers at home (Windows Laptop, Windows Desktop, FreeBSD server). It is also on a USB thumb drive. One of the features of git is that the entire repository comes along with a working copy. Let’s say I’m editing a WikidPad page at home that I already edited on another computer. I don’t have to worry about syncing. I can check in both changesets and merge later. This is a feature that Mercurial also has.
That’s the great thing about text files: they work very well with version-control systems.
I also use the ScrapBook extension from Firefox to archive/annotate pages from the web. The extension saves an index of the pages in RDF format. RDF is a form of XML, which was touted as a better way to save data because it is text-based. Curiously, XML doesn’t work well with any merge tool I’ve come across. I’ll post about my descent down this rat-hole (and how I got around it) later.