RFE: git rm

RFE: git rm

[Jeff Garzik]

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

Re: RFE: git rm

[H. Peter Anvin]

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

Re: RFE: git rm

[Junio C Hamano]

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.

Re: RFE: git rm

[Daniel Barkalow]

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

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

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*

Re: RFE: git rm

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

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

Oh, I do 'git add' myself; otherwise I'd surely forget by the
time I commit.

And I did not mean to tell you to quit doing it.  If any of you
took what I said as "Linus does not do it, I do not do it, so
you should not be doing update-index in the middle", then that
was not my intention and I apologize for causing confusion.

I think update-index in the middle is a valid workflow.  The
only drawback I can think of is that you cannot merge or apply
others' patches once you do it until you commit.  I was just
curious how people use git, weighing the pros and cons of that
(pros: git-diff-files is easier to read and the index gives you
a good anchoring point; cons: you cannot do merge or patch
application).

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

Good point.  Something like this?

 ------------
Clarify git status output.

What we list as "Ignored files" are not "ignored".  Rather, it
is the list of "not listed in the to-be-ignored files, but
exists -- you may be forgetting to add them".

Pointed out by Daniel.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---
diff --git a/git-status.sh b/git-status.sh
index 29c2b11..62a24a9 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -90,7 +90,7 @@ perl -e '$/ = "\0";
 		s|\n|\\n|g;
 		s/^/#	/;
 		if (!$shown) {
-			print "#\n# Ignored files:\n";
+			print "#\n# Untracked files:\n";
 			print "#   (use \"git add\" to add to commit)\n#\n";
 			$shown = 1;
 		}

Re: RFE: git rm

[Daniel Barkalow]

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

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > 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.
> 
> Oh, I do 'git add' myself; otherwise I'd surely forget by the
> time I commit.
> 
> And I did not mean to tell you to quit doing it.  If any of you
> took what I said as "Linus does not do it, I do not do it, so
> you should not be doing update-index in the middle", then that
> was not my intention and I apologize for causing confusion.

Actually, I'm thinking of quitting that because I'm actually more likely 
to realize I need to add something when I see it in the untracked list 
than any other time. Now that the untracked list is right there, I 
probably won't bother to think about it until that point. That is, the new 
feature makes my old habit unnecessary. (I obviously don't care what other 
people do; I'm still using multiple working trees with the same 
repository, which AFAIK nobody else has done for months.)

For that matter, it helps, if I find I've done two things that I want to 
commit separately in the same working tree if the first commit doesn't 
have to include the addition of all the new files.

> > 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.)
> 
> Good point.  Something like this?

Looks like what I was thinking, yes.

	-Daniel
*This .sig left intentionally blank*