Andreas Ericsson <ae@xxxxxx> writes:
> 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:
<hack>
<diff>
<commit>
<hack>
<diff>
<commit>
# 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:
<hack>
<diff>
<add>
<hack>
<diff>
<add>
# 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
