

Git Reset Demystified  - schacon
http://progit.org/2011/07/11/reset.html

======
skrebbel
Everytime I see an article like this, of this length, all to explain a single
git command, I get the feeling that git (and all other decent SCM tools at
that) are way too complex. It's well written and well illustrated, but I feel
like I shouldn't have to read that much just to learn a basic feature of a
tool that's supposed to exist to help me. Is this just me?

Of course, the feeling is strengthened by the fact that I still don't
completely grok git, but shouldn't a tool that's there to help me be easier to
grok? I understood dropbox in 1 minute. I learnt TDD in 3 hours. Why should
(distributed) version control be so much more difficult?

I don't know how, just wondering if I'm the only guy who feels like this.

~~~
silon
Git is not wrong by itself, there's just an impedance mismatch between it's
model and a usable interface model. For most purposes, the index should
completely hidden.

~~~
urschrei
I would respectfully allow that anyone who can't comprehend what the index is
for with the aid of two paragraphs and a diagram should be looking for an
alternate career. The index is important. It's one of the great things about
Git; without it, you wouldn't be able to create commits from a subset of the
difference between your working directory and HEAD. It also has a confusing
name, but here we are.

~~~
skrebbel
> It's one of the great things about Git; without it, you wouldn't be able to
> create commits from a subset of the difference between your working
> directory and HEAD.

I never understood that. I can do this just fine even with TortoiseSVN. Just
click "commit" and select the files you want to include in this commit. I
don't see how I need to keep yet another data structure / piece of "state" in
the back of my head for that. I definitely don't see why I have to look for an
alternate career because of that.

Am I missing something?

~~~
koenigdavidmj
The benefit that the index gets you in such a situation is that sometimes you
are working on two unrelated changes at the same time, but they both touch the
same file. Git (using the -p flag to the add command) lets you interactively
select portions of a file to add to the index.

The interface is pretty simple: it just shows you each small piece of diff to
the files you are adding, and you say whether you want to include that bit of
diff in the index or leave it in the working directory. Alternately, it can
drop you into a view of the diff in the editor, and you can add or modify diff
lines as you please.

~~~
jsharpe
Honestly though, if you're doing that you should be using two different
branches. Which is another thing git is wonderful for.

------
spacemanaki
Scott, thank you so much for all your work on Git tutorials, blog posts,
screencasts and books... I'm sure you know this already but you're a great
teacher!

~~~
devth
I second that. Pure excellence at <http://progit.org/>

------
andrewflnr
It's ironic that this is on the front page at the same time as Linus's
proposal to change to commit object format, in which he claims that the lack
of generation numbers is Git's "only real design flaw" [1]. Okay, maybe he's
only talking about the plumbing, but if it needs long guides like this to
understand one command, I think maybe that would constitute a design flaw.

I like Git, I really do. This article helped me like it more. There has to be
a way to get the benefit of that object model without all the grief at the
interface.

[1] <http://news.ycombinator.com/item?id=2765844>

------
senko
Good overview, for beginners as well as regular users.

In particular _git checkout <file>_ which is (a) not obvious (before stumbling
upon it, I was trying to find it in git-reset documentation), and (b) looks
pretty innocent (as the _git checkout branch_ is quite safe to do if you've
got staged changes.)

------
zby
git is an extremely powerful tool - but it's interface is far from being
smooth - maybe it will come with time. For example the usual pattern of a copy
command is:

copy source destination

The pattern of git push command

push destination source:destination

~~~
fr0sty
1\. There is no built-in copy command in git.

2\. What is confusing about "git push <remoterepository>
<localbranch>:<remotebranch>"

------
yason
Git is like that "one data structure with a hundred functions operating on it,
instead of ten functions operating on ten data structures".

~~~
beza1e1
And that "one data structure" is a directed acyclic graph of objects, where an
object is one of four kinds:

\- blob (like a file)

\- tree (referencing trees and/or blobs, like a directory)

\- commit (referencing one tree and other commits)

\- tag (referencing a commit)

