[OreoCookie]

I've recently switched from subversion to git to manage my drafts of papers (I rely on TeX). I switched to git, because it seems a lot easier to use and it's faster.
With subversion, I could easily check out earlier versions of the draft, after all, the repository was in a different location. git seems to `forget' earlier versions I have submitted when I check out earlier versions of my work.

Code:
bash > git log 
[gives full list of commits]
bash >  git checkout [hash of earlier copy]
bash >  git log 
[gives list up until the point of the checked out copy]

Am I missing something?

Are you supposed to clone your repository and only work on clones?
Is there a way to checkout a previous version of my work without destroying my history?
Or am I simply not using the correct command?

[besson3c]

isn't each commit a new branch with git or something?

I haven't used git yet myself, but I'm intrigued by it. Keep us posted with how your transition to it goes, both conceptually and technologically

[OreoCookie]

The transition was really, really easy. Just compile git with svn support and you can import subversion repositories with a simple command line.

Branches are a lot more useful and much, much easier to use.

Code:
git branch [name of new branch]

Creates a new branch.

Code:
git checkout [name of branch]

switches to the newly created branch. That's it. You can change back and forth at will.

Plus, even though my LaTeX projects are comparatively tiny, subversion was not fast. git does everything `instantly.' Cloning takes as long as copying files (ok, perhaps a microsecond longer). Perhaps I'll ask the mailing list … 

[OreoCookie]

I got it.
If you checkout an older version of your project (or file or whatever), git log will only show you `the past' (the parent nodes of the commit you've checked out). But at the same time, it creates a pseudo branch called `(no branch)' and you can go back to your old version by changing back to the master branch (git checkout master).

Quite simple, if you find it in the manual

[Big Mac]

I am so totally lost.

[OreoCookie]

git can be useful for the average user, too. It gives you revisions of your work and you can create `branches of your work' (similar to versions in Aperture, for instance). It's very useful if you work with a lot of text. Apple has a very good tool that marks differences in files in a visually unique way.

[besson3c]

Oreo: can you walk me through how merges work? Merges are key for me, that's the primary reason I use Subversion (collaboratively)

[OreoCookie]

So I'm not an expert on this, but if you look at all the talks by the inventors, they claim merging is particularly simple. There is a rather simple explanation in this video (scroll to about minute 55-58, depending on where you want to start).

I would also recommend you simply try it out: convert your favorite subversion repository. There are more complex import procedures available if you have tags, etc. etc. From the wealth of documentation, it looks as if you can convert subversion repositories without losing anything. In my case, it worked just fine. You just need the users.txt file to associate user names used in subversion to names and e-mail addresses used in git. Branching really is trivial, literally just the push of a button.

You should definitely install fmdiff and convince git to use fmdiff (at least that's what I prefer), a wrapper which uses File Merge to look at conflicts. If you use TextMate, there are even two bundles for git, I think. Hope that helps.

[Chuckit]

Originally Posted by besson3c 

Oreo: can you walk me through how merges work? Merges are key for me, that's the primary reason I use Subversion (collaboratively)

Git's superior branching and merging are two of its key features.