Git Reset Demystified

http://progit.org/2011/07/11/reset.html

by schacon • 15 years ago

126 54 15 years ago

senko• 15 years ago

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.)

skrebbel5• 15 years ago

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.

spacemanaki4• 15 years ago

You're not, and I think this is where a lot of flamewars between Git and Mercurial users and between DVCS and centralized VCS users start, so I while I don't want to feed the fire, I will only cautiously recommend peeking at Joel Spolsky's Hg Init tutorial, and see if Mercurial is a bit more natural for you, since a lot of people seem to think it's simpler (I have no opinion, mostly because I haven't used Mercurial much).

At the end of the day, for me it boils down to a comment by Xiong Chiamiov, made on one of Mike Taylor's rant-y blogposts about Git, which was much discussed on HN a while ago,

  "I use it because the benefits outweigh all of the things that you mentioned."

Yeah, it's complicated. But a lot of people think it's worth it.

edited to add links to the Reinvigorated Programmer posts, which I recommend reading because there's a ton of good commentary and suggestions for newcomers, even if the discussion got a bit heated:

http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump...

http://reprog.wordpress.com/2010/05/12/still-hatin-on-git-no...

skrebbel5• 15 years ago

Thanks for the advice. However, I felt exactly the same with Hg. In fact, the main reason I have for currently using git and not hg is github.

I'm convinced that indeed it's worth spending more time to grok [git/hg/bzr] and really get the power out of it, but I just can't shake the feeling that somehow, it should be possible to make something with the same benefits that works much easier.

I was hoping that maybe Kiln is exactly that, but from their promo-page all I can see is a rant about how cool DVCSs are, and not much about how Kiln makes Hg easier.

Xurinos4• 15 years ago

It is more that the git API uses terms that have been used in past VCSes in different ways, so it is a matter of helping new users to unlearn their original mental model from older VCSes and to learn the new model. I am mostly convinced that the new definitions of terms are more accurate.

"git reset" in one sentence: git reset allows you to move the HEAD's branch tag to any other git revision. (It is easiest to think about git in terms of labels moving around a tree of nodes.)

skrebbel5• 15 years ago

There you go. What's a "branch tag"? What do labels do in "trees of nodes"?

Mind, I don't mind tackling this kind of complexity when I do algorithms for getting something done. I'm perfectly capable of understanding what you mean if I'd really invest the time in it that I should. But why do I need to do such (relatively) complex yet abstract thinking when I want store a README, undo a mistake and then share it all with a colleague?

chrisledet• 15 years ago

TDD isn't a tool, it's a process of developing software.

This is just the internal stuff, you DONT need to know this using git on a day to day basis. I use git for all my projects and most of the time, i mainly just type `git commit -a -m "lol message" && git push`.

Do you need to know everything about MS Word in order to become productive with it? No. Apply the same concept to Git or any software really.

skrebbel5• 15 years ago

True that, and that's what I do (well, I don't type that command but I right-click in Explorer and choose Git Commit, but I see your point).

I guess the difference is that if there's something that Word can do that I want to figure out, there's good Help and I can get pretty far by scanning the menus. With git, good help exists too (in the form of blog posts like this article), except that the concepts are significantly more complex than those involved in making automatically numbered chapter headings.

In short, to my experience figuring out how to do something non-trivial with Word is exploration. Figuring out how to do something non-trivial with Git is more like studying an advanced CS class.

Jach• 15 years ago

In this case it's a difference in levels of understanding. From the beginning of the article: "I never strongly understood the command beyond the handful of specific use cases that I needed it for." So in that frame of mind git-reset is very simple. "Oh crap, I messed up my working dir and everything's messed up! git-reset --hard!"

The purpose of the article though is to improve understanding beyond that and at an intuitive level. It's the difference between saying Bayes Theorem is p(h|e,c) = p(e|h,c)*p(h|c)/p(e|c) and linking to http://commonsenseatheism.com/?p=13156

The thing I like about git is that yes, as a whole it's pretty complicated, but it's really not that hard to get up and running quickly especially if you use github. Then it's a gift that keeps on giving as you learn more about it while also becoming more proficient. Kind of like vim in a way, which is notorious for its wall of a learning curve, but if you just want to treat it as a normal text editor you can tell it to start up in insert mode and use gvim, then proceed to learn from there.

cpeterso3• 15 years ago

> From the beginning of the article: "I never strongly understood the command beyond the handful of specific use cases that I needed it for."

Note that this comment was written by the author of one of the most popular git books (Pro Git)! His dead tree book is #88 among Amazon's Software Development books. His Kindle book is #16 among Amazon's Software Development Kindle books.

silon2• 15 years ago

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.

urschrei2• 15 years ago

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.

nhaehnle• 15 years ago

In a sense, the index is an acknowledgment of the fact that the operation of "creating a commit" should be a two-phase process, similar to a database transaction.

Phase 1: Choose which parts of the working directory changes should be in the upcoming commit.

Phase 2: Actually commit those changes.

The separation is not entirely clean in Git. While this is very appreciated for convenience (e.g. git commit -a), it blurs the line and does cause confusion.

rlpb• 15 years ago

For me, git is remarkably simple. Its underlying data model is all that you need to understand (and there are only about four major types of object).

Everything about SCM then pops out. I found myself needing tools to manipulate the data model in some way, and a suitable tool always seems to exist.

It's kind of like the Grand Unified Theory of SCM. With such a simple core, everything about SCM just falls out.

I prefer to understand everything in this way so git is perfect for me. But I can understand that it's probably far trickier for people who prefer to learn top-down by starting with workflow and processes rather than from first principles from bottom-up.

dkarl• 15 years ago

It can take a long time to understand something simple but alien. The advantages of familiarity are short-term; the advantages of simplicity are forever.

ajross• 15 years ago

Sure, but there are already "tools to help you" in this realm that are easier to grok.

Early on, developers saved old versions of code via manual copying. That was really easy to grok (Label floppy with "1983 Aug 12", copy, put in box). But it sucked.

So developers invented things like SCCS or RCS, which stored metadata. But they were harder to grok, as now you had to understand the idea of files having history (and branches), and needing to be "checked out" using tools entirely different from standard copying, and being "locked" against change. But they helped, even though they still kind of sucked.

So hackers invented CVS and Subversion, which worked on trees instead of files, used implicit locking and merge algorithms, and generally made life better. But they were yet harder to grok! Now doing regular development meant that occasionally you'd get collisions: you needed to understand the 3-way merge algorithm just to write code. And they still sucked.

So Linus gave us git. Which adds a bunch of new hard-to-grok abstractions like the index and commit ID. But it fixes a bunch of problems too, even if 10 years from now we'll agree that it sucked too.

So pick your point along that spectrum and choose your tool to match your comfort level. In short: your complaints aren't anything new, SCM systems have always been confusing to learn.

gcr• 15 years ago

Why did everything suck? Are we even addressing the problems as we trudge along your linear development path? I think what your parent was getting at is that increasing complexity of SCM software is orthogonal to the problem, which hasn't really been defined well.

It's easy to say that something sucks, but it's harder to say why.

beza1e13• 15 years ago

Git is fundamentally pretty easy, but its terminology is confusing. Maybe this glossary helps:

commit: a snapshot of your files

tag: a reference to a commit

branch: a moving tag

HEAD: the current branch

index: the next unfinished commit

git-add: copy file(s) to index

git-commit: create a commit from the index

git-checkout: copy file(s) from a commit and redirect HEAD

git-reset: redirect current branch to another commit

git-revert: create new commit, which is the inverse of another commit

An interesting thing is that "the next commit" is an object you can work with in git. This concept is new for svn users. With git you can puzzle together a snapshot before it becomes a "real" commit. So mistakes like "Oops, i should not have commited that file" or "Oops, i forgot a little fix in another file" can be handled with git.

sliverstorm• 15 years ago

I personally feel the problem is just the terminology doesn't really match between tools. Coming from SVN, I think of something I want to do and I think of the SVN command for it, but it turns out the Git command is a totally different name, so I spend 10-20 minutes being confused- especially when there is a command of the same name that does something different.

a3_nm• 15 years ago

I agree with you. It seems like the basic concepts are neat and clean, but that the interface to it, and the vocabulary, is counter-intuitive. The article really gives me the impression that git-reset can be used to do several vaguely related things, with an inadequate terminology (--soft, --mixed, --hard?).

Besides, it doesn't help that the first commands you learn about git (like git add, git commit -a, etc.) actually hide most of the complexity in a treacherous way (especially since they do not advertise the existence of the index).

It's probably possible to learn git efficiently by approaching it as something abstract, not as that stuff you want to be quickly productive with. Sadly, you probably can't realize that unless you already wasted your time on the misleading tutorials.

saraid2162• 15 years ago

Git is more comparable to Vi or Emacs than Dropbox or TDD. Or compare it to grep or sed.

The article is intended for deep understanding, not as a tutorial.

spacemanaki4• 15 years ago

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• 15 years ago

I second that. Pure excellence at http://progit.org/

zby• 15 years ago

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• 15 years ago

1. There is no built-in copy command in git.

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

yason• 15 years ago

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

beza1e13• 15 years ago

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)

andrewflnr• 15 years ago

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

Git Reset Demystified

Related Stories