Re: RFE: git rm

> 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.