Re: RFE: git rm

From: Junio C Hamano <junkio@cox.net>
Date: Oct 24, 2005, 20:40 UTC
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.