Main Area and Open Discussion > General Software Discussion

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

<< < (36/39) > >>

Deozaan:
(for instance chapter 2 of Git Internals)-Jibz (July 07, 2015, 04:59 AM)
--- End quote ---

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

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.

--- End quote ---

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)
--- End quote ---

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.

--- End quote ---

toward the end of http://stackoverflow.com/questions/8198105/how-does-git-store-files/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)
--- End quote ---

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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page