Re: git-diff on touched files: bug or feature?

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 3, 2007, 08:40 UTC
Message-ID: <20070803084010.GM20052@spearce.org>
In-Reply-To: <7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> > On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:
> >
> >> Personally, I almost never run "git status".  The command is
> >> there primarily because other systems had a command called
> >> "status", and migrant wondered why we didn't.  We do not need
> >> it, and we do not have to use it.
> >
> > So what is the recommended command to summarize which files have been
> > modified, which files have been marked for commit, and which remain
> > untracked?

git-gui?  ;-)

I also use the following two aliases:

  [alias]
    dw = diff --stat --summary
    di = diff --stat --summary --cached

...

> I do not make partial commits myself, so
> distinction between staged and unstaged are not something I am
> usually interested in.

I never used to either. Then git-gui got really useful at showing the distinction and I started using the index for a staging ground. I almost never make partial commits, unless it is completely trivial, e.g. a comment fixup that isn't related to what I'm really doing but that was too darn obvious to not fix _right now_.

But I always toss things into the index when I've read through the diff a few times and am very happy with it. I may not be done with the overall commit, but I park the hunks into the index so I don't have to look at them again. I use a trackball so "tossing into the index" is really just a flick of the wrist to select the menu item from the pop-up menu on that hunk. Quite like a toss. ;-)

I tend to test only once I have everything staged into the index and my working directory is clean (nothing changed that isn't staged). Its at that point that I think my change is done and I'm happy with how the diff looks. Usually the code is correct at this point too; but if its not I'll fix it, then commit.

So where does that leave me regarding the touched but not changed files? Usually they just get in my way in the end. I don't much care that I've undone the file back to what I had in the index. It just doesn't provide any value to my workflow. It is actually incredible rare that I cause it to happen too. Usually I won't write the file back to disk if I'm just going to undo it.

If I do write it to disk I'm likely to stage it or at least some hunks of it. If I later change my mind and undo those changes I'm going to effectively stage the reverse difference. This is a very nice hint showing me that yes in fact the older way was better.

Personally? The index is a killer feature for me. Totally. I can't work without it anymore, it has become a total crutch to me. You would have to pry the index from my cold dead fingers to get me to stop using it.

Yea, that is a total about-face for me. I used to think the index was only useful for merges. Boy was I wrong!

-- 
Shawn.