Re: [FAQ?] Rationale for git's way to manage the index
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- May 8, 2007, 11:07 UTC
- Message-ID
- <Pine.LNX.4.64.0705081256410.4167@racer.site>
- In-Reply-To
- <46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com>
Hi,
On Tue, 8 May 2007, Martin Langhoff wrote:
> Heh. Making the index very visible makes sense when you are merging,
You're saying that the main use of the index is to help merging. I have to disagree strongly.
When I have been chasing a bug all over the place, and finally found it, my working tree is a mess. Lots of assertions, lots of debugging statements, some of them commented out. So, now it is cleanup time, right?
The problem is that more often than not, I broke my fix while cleaning up.
Therefore, I now put all changed files into the index (git add -u), and clean up the files one by one, always checking with "git diff" and "git diff HEAD" what I still have to do.
Yes, very often I can just take the original version of a file (git reset --soft <file...> would be handy here), but it helped me quite a number of times to have my messed-up-but-working state in the index.
In a sense, I am using the index as the stash commit we talked about every once in a while.
Ciao, Dscho