From: Junio C Hamano <junkio@cox.net>
Date: Mon, 24 Oct 2005 20:40:08 GMT
Subject: Re: RFE: git rm
Message-ID: <7virvmodhz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <435D2FE0.3060307@pobox.com>

Jeff Garzik <jgarzik@pobox.com> writes:

> It would be nice to say "git rm files..." and have two operations occur:
>
> * list of files is passed to rm(1)
> * list of files is passed to git-update-index --remove

This is not a big problem *if* your index always matches the
HEAD tree (i.e. no intermediate git-update-index in between
commits) --- you can just say "rm -f files..." at the point of
removal, continue your work, and either pass these files from
the command line, or -a flag when running 'git commit'.

Running git-update-index in between commits is a valid thing to
do, and it helps reducing the clutter when viewing 'git diff' to
see what your changes look like since your last update-index.
The workflow would go like this:

    1$ git checkout
    ... work work work

    ... what have I done so far?
    2$ git diff
    ... the intermediate result looks OK, so record what we have
    ... done so far...
    3$ git-update-index --add --remove files...

    ... work work work
    ... go back to step 2 as many times as needed.

    ... now what is the sum of changes since the last commit?
    4$ git diff HEAD

    ... everything looks OK.  record the last bits and commit.
    5$ git-update-index --add --remove files...
    6$ git commit

Previously Linus stated that his index almost always matches the
HEAD tree, and I personally do not do intermediate update-index
ever myself, but I am curious how other people use git [*1*].
If some of you run update-index in between commits, "git rm
files..."  would make a lot of sense.


[Footnote]

*1* Cogito users do not count -- they are supposed to leave
index file manipulation to Cogito's smart.