RFE: git rm

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

Jeff Garzik wrote:

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

Install cogito and you have the above as "cg-rm".

	-hpa

Jeff Garzik [off-list ref] 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.

On Mon, 24 Oct 2005, Junio C Hamano wrote:

Jeff Garzik [off-list ref] writes:

quoted

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.

I often do "git add something" when I happen to think of it, not 
necessarily right before committing, which means that I have these files 
changed in my index while working. I may quit this, however, now that git 
status lists the ones I missed.

Incidentally, the new git status entry for --others really ought to say 
something different from "Ignored files", like "Exist but not tracked", 
since it doesn't include the contents of .gitignore, which you'd expect to 
be "Ignored". (And, of course, any files it lists are hardly being 
ignored.)

	-Daniel
*This .sig left intentionally blank*