DVCS ? (All about Git, Mercurial-Hg and the like...)

[Deozaan]

(for instance chapter 2 of Git Internals)

-Jibz (July 07, 2015, 04:59 AM)

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.

[ewemoa]

I've only really used git stashing for "save this current state so it can be returned to later" functionality.

Glancing at the man page, it appears there's a --patch option:

With --patch, you can interactively select hunks from the diff
between HEAD and the working tree to be stashed. The stash entry is
constructed such that its index state is the same as the index
state of your repository, and its worktree contains only the
changes you selected interactively. The selected changes are then
rolled back from your worktree. See the “Interactive Mode” section
of git-add(1) to learn how to operate the --patch mode.

Note that this is for git stash save ...

[Deozaan]

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.

[ewemoa]

For the moment, just this part:

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?

-Deozaan (July 08, 2015, 04:53 PM)

Check out the part that starts:

While that's true and important on the conceptual level, it is NOT true at the storage level.
Git does use deltas for storage.

toward the end of http://stackoverflow...iles/8198276#8198276

I don't know about being more efficient than any other system, but regarding storing deltas, I have seen that claim in a few other places (sorry, didn't find references so far).

[ewemoa]

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.

-Deozaan (July 08, 2015, 04:53 PM)

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

  https://marklodato.g...-guide/index-en.html

There's also this:

  https://git-scm.com/...t-Branching-Rebasing

Do those help at all?

[Deozaan]

Check out the part that starts:

While that's true and important on the conceptual level, it is NOT true at the storage level.
Git does use deltas for storage.

toward the end of http://stackoverflow...iles/8198276#8198276

I don't know about being more efficient than any other system, but regarding storing deltas, I have seen that claim in a few other places (sorry, didn't find references so far).

-ewemoa (July 08, 2015, 05:09 PM)

Aha! So Git stores data contents as blobs, and then stores a delta of the blobs, rather than a delta of the files. That makes more sense. And I also think that also makes sense that it's more efficient than other systems, since (AFAIK) they all store data on a file level. Therefore if you move or rename a file, you get things being stored multiple times.

Thanks! (Now to look into the other links you provided me...)

[irkregent]

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

[irkregent]

I also ran across gitless, which seems to be an easier-to-grok command line replacement for the usual git commands.  No Windows build, though.

[ewemoa]

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.ker...rol_Interface_layers

[Deozaan]

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.

-Deozaan (July 08, 2015, 04:53 PM)

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?

-ewemoa (July 08, 2015, 05:22 PM)

Thanks for these links.

I've been reading more about rebasing from various sources over the past few days (I can't remember specifically from where) and I think I'm understanding it better. In fact, the book that I initially said totally lost me while it described rebasing in the introductory chapter goes into much further detail in the next chapter or two.

I think I've done enough research into Git to feel at least comfortable enough to try it out. And if I can handle it, I may end up making the switch (for future projects) from Mercurial to Git.

Thanks again, ewemoa!

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

-irkregent (July 10, 2015, 03:48 PM)

This looks interesting, but looks like it is specifically for Github. Not for Git in general. I don't use Github for my own repos because they don't allow private repos for free. That said, I signed up anyway because I do have a github account and I do follow/star/watch many repos on Github, and I'm kind of a fan of the whole gist (version controlled pastebin) thing.

[ewemoa]

Good luck

[wraith808]

There's a new one from axosoft in beta - GitKraken.  From the blurb they give on that page, I don't see what's so different, so I'm not trying it out.

[Deozaan]

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.

[ewemoa]

It's nice that there are tools to import / export

I didn't find it easy to get used to git -- certainly took a number of iterations.  In the end knowing about the guts a bit was helpful, but it's not the kind of thing one may enjoy hearing about when all one wants to do is work on one's code...

[Armando]

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.

[Tuxman]

After years of using git, I really learned to love to use Mercurial for my unpaid hobby projects.
git sucks.

[Deozaan]

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

Sample videos and screenshots

-ewemoa (May 31, 2011, 04:28 AM)

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.

[Deozaan]

I had fun with the last one, so I made another: