The gist of this article is “git push is not a backup solution and does not automatically save everything in your project directory to the remote”.
Well, of course git push is not a backup solution. Git is made for sharing and collaborating on a project, not backing up all data about the project. I hope nobody had that misconception. Use standard backup tools like Windows Backup or Time Machine with an external disk, or rsync if you want something command-line for networked computers.
Reminds me of the old joke, “Doctor, doctor! It hurts when I do this…”
“Well, quit doing that, you nit.”
As a git hater, I was disappointed it only boils down to “things that aren’t committed aren’t committed.” I was hoping for more ‘git rebase –forserious’ horror stories. :)
Why do you hate git?
I find the commands to work just a little bit differently than every other vcs. Also, the absurd degree to which I’m expected to learn how it works internally. I’m not interested, and don’t want to be interested, in the how and what.
Or in short: https://pbs.twimg.com/media/BtQnfw2CYAIh123.jpg:large
So honest question, is this more a case of not wanting to deal with it or just the mental shift with the models used within git?
I honestly don’t pay much attention to the git internals and use about 10 commands total with any frequency. I don’t see it all that different, its approach might be a bit unique, but fundamentally it just version controls file contents.
As long as I work solely with master, it’s not too bad. I pull; I push; I commit (don’t forget -a!). Once branches are introduced, though, I’m lost. Do I have the branch; do I not have the branch?
As near as I can tell, git fetch and hg pull are roughly equivalent. (ironically, git pull and hg fetch also seem to be equivalent.) Compare the help though.
git-fetch - Download objects and refs from another repository
hg pull - Pull changes from a remote repository to a local one.
Fetch branches and/or tags (collectively, "refs") from one or more
other repositories, along with the objects necessary to complete their
histories. Remote-tracking branches are updated (see the description of
<refspec> below for ways to control this behavior).
This finds all changes from the repository at the specified path or URL
and adds them to a local repository (the current one unless -R is
specified). By default, this does not update the copy of the project in
the working directory.
Basically, what I want is pretty simple: I want those changes, over there, to show up over here. I would prefer not to ponder such things as remote-tracking branches and the objects necessary to complete their histories. At every step, though, git is like “this command performs the following physical operations. I’ll leave it up to you to decide if those physical operations correspond to your desired logical operation.”
Ah yeah the git documentation, its pretty abhorrent I can’t argue that unless to play devils advocate. You might like this page for fun:
A fun one I just got:
git-drug-index drug some non-exported remote indices over all indexed non-prevented upstream bases
As for git pull/fetch its basically as you’ve posited the same(ish) as hg fetch/pull. That is git fetch will snag remote changes and put them locally, but not modify files. git pull will effectively git fetch and git merge to apply the changes.
How did I learn this? Well I guess I’m weird but I tend to ignore the docs and create test repos to run the commands. That said part of why I reverse engineered git is the docs basically felt like a markov generator had written it.
As for branches, I’m confused, they’re effectively not all that different from master (which you can delete if you like for that matter). One thing that helped me understand was using git-cola which shows you the dag that is happening underneath.
I found that to be really helpful to understanding gits view of branching. I’ll agree the effort to understand why git foo really is just doing xyz is dispraportionate to other vcs’s. I’ll lay that one on the developers not really seeming to care what the users interface looks like. Then again I tend to just use emacs+magit now so I really don’t deal with git itself often. I’ll recommend that as well. I find it better/easier than using hg/svn/cvs directly.
As someone who enjoys git, neener, neener. ;-)
Anyone know if hg is similar?
If you’re using similar features (mq, shelve, etc.) that “save” work but not really, yes. In my experience, the hg community places less emphasis on rebase like operations, so you’re less likely to end up with hidden orphaned branches in your repo that don’t get pushed.
We also have things like evolve so that, even if you do a destructive operation, you can trivially see all prior versions of a patch. This goes way beyond Git’s reflog, both because it can be transmitted, and because it’s tracking the history of each patch, not just where all branch markers previously were.
That said, I think it’s insane, this modern concept that your history should be pristine. It’d be like insisting each draft of your essay be a perfect, smaller version of the final draft. That’s neither how coding nor writing work, and I don’t find any meaningful value in the practice.