Hacker News Reader

Comment by llimllib | Hacker News Reader

just "git commit" after that, not "git commit README.md"

edit: it's infuriating that yc won't let me reply to you, so I have to reply in this edit. Anyway.

"git commit" says to git: "move anything in the index (i.e. things which I have 'git add'ed, or which have been merged) into the local repository".

"git add FILE && git commit" says "put FILE in the index and then commit the whole index to the local repository"

"git commit FILE" says "assume the index is clear, and only commit FILE" to which git says the logical response, "sorry, dude, the index isn't clear, I can't do that"

perhaps this will help: http://osteele.com/archives/2008/05/commit-policies

View on HN

Oh! Well, thank you. Yes, I see that that works.

But:

(A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and

(B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.

> (A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and

'git commit' commits everything that is currently in the index. 'git commit -a' commits all files currently tracked by git in their current state (if the version in the index and in the working directory differ, IIRC, the version in the working directory is used). It's the equivalent of a "git add FILE" for all tracked files with outstanding changes, right before a 'git commit'.

> (B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.

The index is meant to be the 'staging area' where you can pick and choose what you want to commit. See "git add -p FILE" for an example of more complex usage of the index than just picking and choosing which files to commit.

In general, think of 'git add' as your ability to promote changes from the working directory to the index, and 'git commit' as your ability to create a commit from the contents of the index.

> you can pick and choose what you want to commit

How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the contents of the index. To me, making a commit that I've never tested is somewhere between sloppy and negligent, so why is git encouraging me to do it?

I think that your issue is that you're thinking of a commit in git in the same way that you would think of a commit in svn. They are not the same. To commit in svn you are forced to push to the remote repo. Therefore you screw everybody up if your commit hoses things. In git, you can commit locally, and you are not even required to push those changes out. You could trash those commit without anyone ever knowing that you made them. You could make small atomic commits of small changes, and when the feature is ready to be pushed out to the 'canonical' repo, you could squash all of those small commits into one large commit, then push it out.

After some reading, it looks like it's actually possible to use git-checkout-index after an uncommitted merge to get the index contents out where I can test them. I'm still mystified that the preferred workflow is to blindly commit stuff that may not even run, which leaves you with the problem of somehow knowing which of the commits are actually useful points to roll back to or start new work from.

This is a bit of a late reply, but the reason it's committing everything that your colleague changed is that it's the definition of a merge commit.

I find that it's desirable to avoid merges to reduce the number of overall commits. To do this, do git pull --rebase instead of just git pull when your commit is rejected.

This is exactly the kind of unintuitive behavior that he was complaining about.

The thing is that it is intuitive if you only take some time to learn the new tool's features and how it is effectively used. Simply treating it like svn wont work. Yes you can 'get by' with some svn-like behaviors, but really dvcs is an entirely new thing you will have to learn to make sense of.

Here's an analogy. Svn is a horse and git is a car. You can imagine all these horse-riders (and there are tons of them) sitting around in a bar saying to each other "these new cars? What is up with them? It makes no sense that you change 'gears' and push pedals to stop and go! I just want to <insert whatever you do to ride a horse> and I'll get to my destination!" -- Well, yea, horses work fine a lot of the time. But it's 2010 (1910? :)) and I have more eclectic needs in my change management. I'm willing to invest some time in learning it just like I was willing to invest time into learning vim, or Erlang, or anything else of value.

Reply on news.ycombinator.com