Git Magic

'git checkout HEAD' fails unless your tree is clean. 'git reset --hard HEAD' will throw your
changes away, but that's fairly difficult to type unless you know what you're doing. ('git
stash' is worth looking at if you're often trying to move around with uncommitted changes in
your tree.)

"git checkout HEAD" doesn't do anything (expect possibly display a bit of useful information).
It's "git checkout HEAD ." (note the filename "." at the end) that will discard uncommitted
changes, because (like in CVS), it's a request to cause the working directory to match "HEAD"
with respect to the path ".".

But I think that section shouldn't really be in that document; it's talking about a
non-recommended method for keeping two computers in sync by confusing one of them and then
intentionally losing the false changes that the computer thinks it has.

Git is actually extremely careful about uncommitted changes. The only ways to lose uncommitted
changes with git are to either ask to discard them (with "checkout <filename>" or "reset") or
ask to have working-directory files modified or removed (e.g., "apply" or "rm"). By default,
git won't even overwrite modified working directory files with merge results like other
version control systems will.

My bad: in the old days, git was less forgiving. As others have noted, nowadays a checkout
fails on unclean trees. That is, unless you specify particular paths in which case only those
particular paths are overwritten. I've updated the guide to reflect this.

Every time I go into a sub directory in /etc to edit a file for config for the first time the
first thing I do is:

git-init-db; git-add .; git-commit -m "Initial Version"

I'd tried various approaches with CVS before but it quickly turned ugly. Now I can easily roll
back changes, start again or fork of in a new direction without loosing track of what I did
and why.

git push only works if your "origin" is somehow magically configured in a dotfile which is
very poorly explained deep in the 50th page of the manual.  Unless that's been fixed in the
last year or so.

I think there's several questions buried in there. One thing you'd probably like if you
haven't seen it already is (type it exactly as shown)

git log origin..

This asks for a log of commits between 'origin' and your present reference which is probably
the HEAD of your local repository or a branch thereof. 'origin' is the remote repository
(either set up manually following the convention, or as a result of using 'git clone')

Thus, anything on this list has been committed locally but not pushed upstream yet and it's
your responsibility to back it up or push it if you don't want to lose the changes when your
5yo nephew throws the laptop into the bird pond.

Of course you also want to look at 'git status' for reassurance that you don't have any
changes that aren't checked in locally. But after a little while using 'git' you get so used
to the speed and convenience of local commits that you use them with the same unconscious ease
that you use the "save" feature in your text editor of choice.

Actually, everybody uses what git calls branches in CVS (although CVS branches are something
different). If you're doing work in your local directory, and someone else makes a commit to
the central server, you don't see that change until you update; these two simultaneous
different states of the same project are what git calls branches. Git just makes this
explicit. Furthermore, everybody uses CVS's basic merging in update, and git is pretty similar
in the same situations.

The main difference between CVS and git in this regard is that CVS requires you to resolve
conflicts before committing, and git requires you to commit before resolving conflicts.
Obviously, if you sometimes fail when trying to resolve conflicts, git is nicer (because you
can get back your version and try again or try merging with only some of the changes at a time
or something).

epa wrote: "99% of people do not use branches in CVS or Subversion"

Of course, they don't, because it is so painful with CVS or Subversion that people go at great
length avoiding them wherever possible. But Git developers use branches not because they are
"cool features", but because their usage significantly simplifies and speeds up development.
And the speed at which Git develops is the best testament to that.


epa: "how the differences between your local directory (whether changes have been committed or
not) and some remote repository"

If you already fetch changes from that remote. Then you can run:
git diff remote-name/branch-name


epa: "With svn, you can commit something and know that it's definitely there on the server,
being backed up every night."

The difference is that with SVN, you CANNOT backup your work in progress, while Git allows you
to that easily. You can backup all your local repo on the server (or even on a few servers if
you are really paranoiac). You can do that automatically on every commit or follow whatever
backup policy you like. Git is fully distributed system and mirroring changes is not a problem
at all!


epa: "You can say 'svn status' for reassurance that you don't have any changes which are not
in a safe place."

And that is how the central CVS and SVN repositories slowly but surely are turning in mess...
Just let any developer to commit without review and proper testing, just because they feel
that they need to save their work at the end of their day, and you are going to have a lot of
mess soon.

BTW, in respectable companies like Google, there is such a thing as code review, which means
that you can wait sometimes for days (happens even for weeks!) before you can check-in...

Even without code review, the full cycle of testing and building on different platforms and
different configurations may take hours. Are you going to wait at the end of your working day
when these tests have finished?

With Git, you are going home knowing that your changes are properly backed and in testing now,
and if results are okay (and you do not have to wait for someone's else approval), you can
push changes to the official repo. (In some workflows, most developers never push to the
official repo. So just send an email to the team lead saying that you have accomplished the
task, and then the team lead will either pull those changes or get back to you saying what
s/he does not like about your changes.)

"Is there a true equivalent of 'svn diff', that is, show the differences between your local
directory (whether changes have been committed or not) and some remote repository?"

'svn diff' doesn't touch the repository either, unless you give it URLs.

> How do you get that same warm fuzzy feeling with git? 

Perhaps you could use git push --dry-run to see that nothing needs to be pushed to the server.

With respect to server backups, it's worth noting that since each developer keeps a full copy
of the repository, this by itself works as a distributed backup.