(for instance chapter 2 of Git Internals)

OK, why the smurf is that PDF written/designed in landscape mode?

But thanks for the other tips. I never really messed much with SourceTree for committing things. But after playing around with it for a few minutes, prompted by your tip, I do feel that it (using a Git repository) actually gives me more control than TortoiseHg (Mercurial repository) does to stage specific lines of code rather than what it calls entire hunks. That's really cool!

The Stash feature seems to be an all-or-nothing affair, which, if true, seems a bit unfortunate. I'd love to have the same level of control as the staging area for what I want to stash and what I don't. But with the optional exception of "keeping all staged changes", it seems to stash every change, reverting the repo back to a clean slate. Bummer!

EDIT: After further testing, SourceTree seems to work the same way with Mercurial shelves. But it's actually worse since there is no staging area, so it really is all-or-nothing. That's too bad. I know from TortoiseHg that shelving can be much more selective/precise than that. But I guess that lets me know that Git Stashes could probably be more selective as well if I had a better tool to do it.

I read through Chapter 2 of Git Internals and almost all of it made sounds and sounds really nice. But I have to admit I got totally lost on the subject of rebasing. Usually when I had trouble following the descriptive text, I could look at the illustrations and figure out exactly what was going on. But I'm still not grasping how rebasing works or exactly what it does after having fully read the text and studied the illustrations for some time.


Also, I'm a little confused about something with regard to how Git stores blobs. I like how it doesn't care about files or filenames, and that if the content is the same, it will only store it once. But doesn't that mean if you make one tiny change to a file, it has to store the entire file again as if it was a brand new file? Shouldn't that make the size of the repo huge?

On the other hand, as I understand Mercurial, it stores diffs, but this can mean that duplicate files or move/renamed files are stored multiple times in the same repo, increasing storage size as well.

I do rename or move files occasionally, but I modify existing files a lot more often than I move/rename them. But doesn't this fundamental difference in how each DVCS store data mean that Git repos will generally be larger than Mercurial repos? Or is there something else I'm not grasping?


Finally (at least for now) I'm still a bit unsure about Garbage Collection. Or the fact that in Git, parts of your history can simply disappear. It seems worrisome that things can disappear and be as if they never existed in the repo. In some cases, I can see how that would be nice (like if you accidentally included a file you didn't have permission to distribute), but the description in Chapter 2 seemed to indicate that things would somewhat often be garbage collected through normal use of Git. Scary! I had assumed that to make things disappear as if they'd never existed, it would require some advanced and very intentional edits to the history.

Maybe I just haven't yet gotten to the part where he goes into further detail about what circumstances will cause garbage collection which will allay all my fears/concerns, but for now with what little info I have about it, it's somewhat alarming.

But I have to admit I got totally lost on the subject of rebasing. Usually when I had trouble following the descriptive text, I could look at the illustrations and figure out exactly what was going on. But I'm still not grasping how rebasing works or exactly what it does after having fully read the text and studied the illustrations for some time.

Among other things, the following has a section on rebasing with images:

  https://marklodato.github.io/visual-git-guide/index-en.html

There's also this:

  https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Do those help at all?

Just to muddy the waters here a bit, it looks like a new desktop version of git is coming, promising "the same, native experience on OS X and Windows operating systems":
desktop.github.com

Hadn't seen that one -- thanks for mentioning it.

If that sort of thing is of interest, perhaps the following will be too:

  https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Version_Control_Interface_layers

Good luck

I tried working on a project and got so sidetracked trying to get git to work the way I wanted to that I moved the project to Mercurial so I could actually work on the project instead of spending all my time fiddling with git.

What I've ended up doing is being productive using Mercurial, then when I get to a place where I'm ready for the cloud builder to make a test build for me, I copy all the files over to a separate git repo to add/push the changes to let the cloud do its job.

I probably just need more time to force myself to learn the git tools, but right now I'm finding it really hard and frustrating to do things that are so easy and natural for me to do using Mercurial's tools.

I found that for most day to day code work, it's pretty straight forward (committing stuff, creating branches, merging branches, rebasing, stashing, squashing, blaming, etc.). Especially with a nice gui. But then, I didn't use the more advanced functions that much.

Came across gource -- "a software version control visualization tool" -- anyone tried it out?

Sample videos and screenshots

I'm replying to a post made 5 years ago.

I recently re-discovered Gource and, seeing that I now have several Mercurial repositories I could test it out on, decided to give it a try.

Here's a video of one of my smaller projects, Be Tiny, World!:


It's kind of fun seeing the history visualized like that, and being able to remember what stage the project was in when certain files were added/edited.

The first few seconds (April 2012) are my Ludum Dare 23 submission. Then I ported it to Android (May). Then I improved the GUI a bit (February 2013). Then I added Google Play Games Services (Achievements/Leaderboards), gave it a major graphical upgrade, and added a super easy "Kid Mode" to the game (September 2013). Then I put it up on Itch.io (Octoberish). Then I added a Twitter Bot to tweet out about people playing the game (April 2014). Then I added Immersive Mode (on Android) and replaced a deprecated Google Play Games Services package with a new one (November). And that was my last update to the game.