Re: Question about "git commit -a"

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Oct 5, 2007, 12:45 UTC
Message-ID: <vpq641livbf.fsf@bauges.imag.fr>
In-Reply-To: <47062CD7.70400@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 7 quoted lines

> He. It's like comparing a duracell battery to the sun, but yes, that's
> one of the operations where the index is involved. But after doing your
> git-add thing above, you could also have continued hacking on A B C D,
> and git would only have committed the state where you did "git add".
> When you stop to think about this, you'll realize that it's a really
> powerful thing, as it lets you keep on hacking even when you don't
> really know where you'll end up.

That usage is indeed very close to a micro-micro-throwable branch.

Instead of doing:

# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want
$ git reset --hard HEAD^^       | $ git checkout HEAD^^
                                | $ git merge --squash HEAD@{1}
                                  (untested)

You'd do:

# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want $ git reset --hard | $ git commit

The two flows are both similar and different. In the first case, you can't come back to an arbitrary step within your development, but since you didn't actually commit, and just ran "add", it's precisely because you thought this state was not one you wanted to come back to later. And at the time you commit, you don't have to tell git to forget about the temporary branch, the succession of "git add" was just for you, not to keep in history.

Actually, most of the time, I commit only when my index matches the working tree (i.e. when status shows me only green, with color.status = auto), so "commit" or "commit -a" don't change the result, but I validate my own changes with "add", and give the whole thing a descriptive message with "commit".

-- 
Matthieu