

A List Apart: Get started with Git - lukasz
http://www.alistapart.com/articles/get-started-with-git/

======
duck
The best part of Git? More and more people are using version control and a lot
of them aren't even developers. Just like Rails, the community and the social
effect (aka GitHub) have made this possible.

~~~
spacemanaki
How well does git handle non-text files like .psd and .ai files?

~~~
stellar678
I have a git repo that seems to do fine handling binary files of 1-200
megabytes that regularly update.

The downside is that the repo grows by that much every time I update the file.
The upside is that I get a version history if I need to back out to an older
version!

~~~
ryanpetrich
Also, you can't diff or merge them.

~~~
nickik
Thats not gits fault. It would need to know how the programm that preduced the
file does updates or some professor somewere has to figure it out on bitlevel.

~~~
sudont
With the push in the design community to create some sort of replacement for
psd comps, I could see a new file type becoming accepted.

The problem is that web design inevitably ends up in pixels, and I will always
have to move to that level to tweak, anathema to version control.

------
bbsabelli
If you use textmate:

    
    
      git diff | mate -

~~~
blaix
What is the trailing slash for?

~~~
pyre
A lot of command-line programs that operate on files take '-' as placeholder
for stdin or stdout. For example:

    
    
      wget -O - 'http://news.ycombinator.com' | less
    

The -O option is for specifying an output file, but the '-' says to dump the
contents to stdout.

~~~
pjscott
Funny; I always use the curl command for that kind of thing, since it
automatically pipes to stdout -- but there's something fun you can do with
that, too:

    
    
        curl http://example.com/foo.tar.gz | tar zxf -
    

Tar's input file is "-", which means stdin. This downloads and decompresses a
tarball to the current directory, without creating a temporary file that I
have to delete later.

------
alexwestholm
Mercurial is another feature rich DVCS. Joel Spolsky has done an excellent job
of providing a similar beginner-friendly introduction at <http://hginit.com>.
It's short, easy to understand, and pretty funny in places.

------
shubber
I'm really tired of Git standing in for "DVCS" - there are so many better
options. Bazaar, Mecurial, Monotone, Fossil - check those out. The only win I
see in git is the adoption rate. Which doesn't seem like a real win, just
populist shackling.

~~~
apl
Would you mind explaining why Git is inferior?

~~~
shubber
A big problem with git is that the commits-and-branching model is poorly
thought through. It's very easy to find yourself on no branch at all, for
instance, or for a developer to believe they've committed work to a shared
branch when in fact it's a private one (and therefore leave the rest of the
team hanging.)

It's merging workflow is awful - I'm fine with correcting the odd whitespace-
as-conflict, but I find the fact that git presents me with >>>>> eyebiting
====== conflict markers <<<<<< even when I'm using a merge tool difficult to
excuse.

Most of all, more than once, git has completely eaten work, which hasn't
happened to me with a VCS since the days of CVS and corrupted repos.

Frankly, I see two kinds of arguments in support of git: arguments that derive
from the fact that it's a DVCS, and therefore apply to other (IMO better)
tools, or "community acceptance" (a la github, Rails) which I find frustrating
and circular. Oh, and it's somewhat faster for infrequent operations.

~~~
trustfundbaby
> A big problem with git is that the commits-and-branching model is poorly
> thought through

Really? I think that is one of its strongest points. being able to switch
branches by just going 'git checkout <branch>' and immediately having the
entire file structure switched out to what's 'contained' in the new branch was
a big win for me.

Git also alerts you when you've made changes and are switching branches, so
you can commit or stash your changes to the branch you were on and not mix it
up with the new branch, unless thats what you really want to do.

> It's very easy to find yourself on no branch at all

Interesting. In what situation would that happen? I always thought you had to
be on some sort of branch (master) at least to use git.

> It's merging workflow is awful - I'm fine with correcting the odd
> whitespace-as-conflict, but I find the fact that git presents me with >>>>>
> eyebiting ====== conflict markers <<<<<< even when I'm using a merge tool
> difficult to excuse.

Sounds like we're complaing about a cosmetic issue.

> Frankly, I see two kinds of arguments in support of git:

How about the fact that its branching model is pretty awesome and it gives you
the tools to do exactly what you want with your version control (rebase,
amending commit histories etc)?

~~~
shubber
"Really? I think that is one of its strongest points. being able to switch
branches by just going 'git checkout <branch>' and immediately having the
entire file structure switched out to what's 'contained' in the new branch was
a big win for me. Git also alerts you when you've made changes and are
switching branches, so you can commit or stash your changes to the branch you
were on and not mix it up with the new branch, unless thats what you really
want to do."

Cheap branching is a fantastic feature - that all the open DVCS tools have.

Git focuses on the ability of developers to edit their revision history and
provide lovely linear histories (hence the existence of stash, rebase, et al).
Git as a tool and as a community encourages one to do so - but the result can
be that your local repo and my local repo can no longer be synchronized.
Furthermore, it's easy to create a commit of inconsistent code - since you can
commit file changes in separate commits.

Ultimately git simplifies the work of project maintainers at the expense of
day-to-day development, which isn't surprising given it's source, but I think
it's a bad trade.

~~~
jrockway
_the result can be that your local repo and my local repo can no longer be
synchronized_

Nope. All rebase operations create a brand new branch and merely repoint a ref
at it. The original pre-rebase branch is still untouched, and "git reset
HEAD@{0}" (see: git-reflog) will reverse the effects of any rebase (and of
course, you can undo the undo). Rebase does not affect synchronization in any
way except that two users may have very different commit histories that they
both call "master". Git handles the synchronization fine, however, so this is
a social issue rather than a technical issue. I regularly work on large
projects with many committers that rebase, and I have never had any
difficulty. Hell, git pull even defaults to "git pull --rebase" now, so you
probably won't even see any merge commits when you pull from someone's rebased
branch now.

 _Ultimately git simplifies the work of project maintainers at the expense of
day-to-day development_

I disagree again. Git makes both day-to-day work easy, and it makes
maintaining the project easy. When you are in hacking mode, you just commit
with a short message whenever you feel like it. Commit freely, branch freely,
merge freely, undo freely. When you are done and you want to cleanup your work
to share, you can quickly split commits, combine commits, reorder commits, add
better commit messages, and so on. Then, you can push to a public repository,
ask someone to pull your branch, or just email patches around. If you mess it
up somewhere, everything is undoable. Git even has tools to make merge
conflicts easy to handle; if it sees a conflict you've manually repaired
before, it can automatically try that repair without bothering you again.

Anyway, it's clear that some people take issue with people "rewriting history"
and that they will never use git. But I take issue with having to maintain
projects that have an incomprehensible (but "historically accurate" in the
sense that I know exactly what the state was when some random person on the
Internet typed "commit") history, and so I use git. It is the most efficient
use of my time and mental energy, and is why its become so popular.

------
9ec4c12949a4f3
I'm glad to see the increase in GIT tutorials, about a year or two ago there
wasn't anything out there except confusing circles that you spin in for people
who already know GIT.

Perhaps a blog like the daily VIM might be a great idea for any keen hackers
out there.

~~~
eru
I started git earlier than a year ago. You can just read the documentation
that comes with git. It's understandable (at least if you are a hacker).

~~~
9ec4c12949a4f3
Sorry I didn't precisely mean understandable. I mean that's now how your
average user wants to learn the system. If I can't figure it out in 3 minutes
I go "screw this, it's complicated" and go away back to "File-> save as->
TheEntireProject-Backup2-version8-March11-2009.code" again.

But maybe I shouldn't be concerned with programmers like that.

~~~
eru
You were right that git wasn't approachable for normal people.

