How to commit removed file?

How to commit removed file?

[Michael S. Tsirkin]

I'd like to remove a file and commit the removal while
leaving out other changes in repository/index.

$git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'

$ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
any file(s) known to git.
Did you forget to 'git add'?

A similiar thing works with "git add".


-- 
MST

Re: How to commit removed file?

[Johannes Schindelin]

Hi,

just a guess: putting "--" before the name of the removed file should 
work, no?

Ciao,
Dscho

Re: How to commit removed file?

[Michael S. Tsirkin]

> I'd like to remove a file and commit the removal while
> leaving out other changes in repository/index.
> 
> $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> 
> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> any file(s) known to git.
> Did you forget to 'git add'?
> 
> A similiar thing works with "git add".

Any ideas? Can this be done with git?

-- 
MST

Re: How to commit removed file?

[Johannes Schindelin]

Hi,

On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:

> > I'd like to remove a file and commit the removal while
> > leaving out other changes in repository/index.
> > 
> > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> > 
> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> > any file(s) known to git.
> > Did you forget to 'git add'?
> > 
> > A similiar thing works with "git add".
> 
> Any ideas? Can this be done with git?

Did you actually try the "--" thing I suggested in 
http://article.gmane.org/gmane.comp.version-control.git/35699/?

Besides, I just tested with current "next": 

$ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
 1 files changed, 0 insertions(+), 22 deletions(-)
 delete mode 100644 a234

Re: How to commit removed file?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
>
>> > I'd like to remove a file and commit the removal while
>> > leaving out other changes in repository/index.
>> > 
>> > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
>> > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
>> > 
>> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
>> > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
>> > any file(s) known to git.
>> > Did you forget to 'git add'?
>> > 
>> > A similiar thing works with "git add".
>> 
>> Any ideas? Can this be done with git?
>
> Did you actually try the "--" thing I suggested in 
> http://article.gmane.org/gmane.comp.version-control.git/35699/?
>
> Besides, I just tested with current "next": 
>
> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
>  1 files changed, 0 insertions(+), 22 deletions(-)
>  delete mode 100644 a234

The difference is Michael did "git rm" to explicitly tell git to
forget about that path, while you used the vanilla "/bin/rm".

Personally I never saw the point of having "git rm".  Maybe we
should remove it to prevent this confusion from happening.

Re: How to commit removed file?

[Jakub Narebski]

Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
>>
>>>> I'd like to remove a file and commit the removal while
>>>> leaving out other changes in repository/index.
>>>> 
>>>> $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
>>>> rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
>>>> 
>>>> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
>>>> error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did
not match
>>>> any file(s) known to git.
>>>> Did you forget to 'git add'?
>>>> 
>>>> A similiar thing works with "git add".
>>> 
>>> Any ideas? Can this be done with git?
>>
>> Did you actually try the "--" thing I suggested in 
>> http://article.gmane.org/gmane.comp.version-control.git/35699/?
>>
>> Besides, I just tested with current "next": 
>>
>> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
>> Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
>>  1 files changed, 0 insertions(+), 22 deletions(-)
>>  delete mode 100644 a234
> 
> The difference is Michael did "git rm" to explicitly tell git to
> forget about that path, while you used the vanilla "/bin/rm".
> 
> Personally I never saw the point of having "git rm".  Maybe we
> should remove it to prevent this confusion from happening.

Does this happen with new git-rm, which removes file also from
working directory?

BTW. you probably can do this with git-update-index...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: How to commit removed file?

[Johannes Schindelin]

Hi,

On Tue, 2 Jan 2007, Junio C Hamano wrote:

> The difference is Michael did "git rm" to explicitly tell git to forget 
> about that path, while you used the vanilla "/bin/rm".

Ah. In this case, it is enough to just say "git commit"...

> Personally I never saw the point of having "git rm".  Maybe we should 
> remove it to prevent this confusion from happening.

People seem so used to "cvs remove" that they had to have "git rm". Dunno. 
I never used it. (Except to verify that indeed even "--" does not work 
with Michael's example.)

Ciao,
Dscho

Re: How to commit removed file?

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Tue, 02 Jan 2007 13:40:41 -0800, Junio C Hamano wrote:
> Personally I never saw the point of having "git rm".  Maybe we
> should remove it to prevent this confusion from happening.

The one place where it's really "necessary", (as opposed to some users
just expecting it to be there), is to "undo" a git-add, (and I mean a
git-add that actually adds a new path to the index, not one of these
newfangled git-adds that simply updates content for an existing path).

For that scenario, without git-rm, the user would be forced to learn
how to use git-update-index to solve this problem.

(And note, that this is also the one case where it's the _right_ thing
for git-rm to actually leave the file around. I haven't checked to see
if the latest round of git-rm semantic cleanups still handle this use
case correctly.)

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: How to commit removed file?

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> On Tue, 02 Jan 2007 13:40:41 -0800, Junio C Hamano wrote:
>> Personally I never saw the point of having "git rm".  Maybe we
>> should remove it to prevent this confusion from happening.
>
> The one place where it's really "necessary", (as opposed to some users
> just expecting it to be there), is to "undo" a git-add, (and I mean a
> git-add that actually adds a new path to the index, not one of these
> newfangled git-adds that simply updates content for an existing path).

"git reset" (i.e. --mixed) is the way to revert the index back
to HEAD and start over.

Re: How to commit removed file?

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Fri, 05 Jan 2007 17:57:16 -0800, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
> > On Tue, 02 Jan 2007 13:40:41 -0800, Junio C Hamano wrote:
> >> Personally I never saw the point of having "git rm".  Maybe we
> >> should remove it to prevent this confusion from happening.
> >
> > The one place where it's really "necessary", (as opposed to some users
> > just expecting it to be there), is to "undo" a git-add, (and I mean a
> > git-add that actually adds a new path to the index, not one of these
> > newfangled git-adds that simply updates content for an existing path).
>
> "git reset" (i.e. --mixed) is the way to revert the index back
> to HEAD and start over.

But that's a lot more than I want.

Here's something like one of the original use cases that I hit and had
in mind (as best I recall) that motivated be to write the initial
git-rm command. It was something like adding a feature and a new
test-case at the same time:

	git update-index src/Makefile
	git update-index src/some-feature.c
	git add test/feature-test.c
	# Hmm, wait, it'd be cleaner to add test/feature-test.c as a separate
	# commit. How can I undo that "git add" I just did?

So, at this point, I could git-reset and start over, but I wanted a
way to undo just the "add" and leave all the other updates still in
the index.

It's not really all that important to be able to undo the add,
(there's not really a corresponding way to selectively undo the other
update-index calls without using git-reset for everything).

But now that I tried this case with a recent git (2a3a3c247) for which
git-rm does working-tree removal without -f, I see that it does
irretrievably destroy information in this case:

	$ echo "important stuff" > new-file
	$ git add new-file
	$ git rm new-file

This now deletes new-file from the working tree and there's no copy of
the data inside git. The old git-rm would just return the file to it's
"untracked" state in this case.

I had thought the safety check was going to be that the index state
matched the HEAD state before git-rm would delete from the working
tree.

(Note, that I definitely agree that it's an improvement that git-rm
does delete the working-tree file when the working-tree and index and
HEAD all have the same content.)

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: How to commit removed file?

[Jakub Narebski]

Carl Worth wrote:

> But now that I tried this case with a recent git (2a3a3c247) for which
> git-rm does working-tree removal without -f, I see that it does
> irretrievably destroy information in this case:
> 
>         $ echo "important stuff" > new-file
>         $ git add new-file
>         $ git rm new-file
> 
> This now deletes new-file from the working tree and there's no copy of
> the data inside git. The old git-rm would just return the file to it's
> "untracked" state in this case.
> 
> I had thought the safety check was going to be that the index state
> matched the HEAD state before git-rm would delete from the working
> tree.

That is certainly bug in new git-rm; it should remove file _only_
if it can be recovered with the same state as it was before git-rm. 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: How to commit removed file?

[Michael S. Tsirkin]

Mutt Label Removed By VIM
> Quoting r. Junio C Hamano <junkio@cox.net>:
> Subject: Re: How to commit removed file?
> 
> >> > I'd like to remove a file and commit the removal while
> >> > leaving out other changes in repository/index.
> >> > 
> >> > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> >> > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> >> > 
> >> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> >> > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> >> > any file(s) known to git.
> >> > Did you forget to 'git add'?
> >> > 
> >> > A similiar thing works with "git add".
> >> 
> >> Any ideas? Can this be done with git?
> >
> > Did you actually try the "--" thing I suggested in 
> > http://article.gmane.org/gmane.comp.version-control.git/35699/?
> >
> > Besides, I just tested with current "next": 
> >
> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> > Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
> >  1 files changed, 0 insertions(+), 22 deletions(-)
> >  delete mode 100644 a234
> 
> The difference is Michael did "git rm" to explicitly tell git to
> forget about that path, while you used the vanilla "/bin/rm".
> 
> Personally I never saw the point of having "git rm".  Maybe we
> should remove it to prevent this confusion from happening.

But won't the same problem appear with

rm file
git-update-index file
git-commit file

-- 
MST

Re: How to commit removed file?

[Junio C Hamano]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

> But won't the same problem appear with
>
> rm file
> git-update-index file
> git-commit file

If you do index manipulation yourself using update-index, do not
jump the index at the commit time using "git commit file..."
syntax; the sole purpose of that misfeature is to handhold
CVS-braindamaged people who want to make per-path partial
commits.

We bend backwards to allow index-jumping for most cases in
git-commit, and you found that "most" is not "all".  That's a
great news.

I am not interested to make it "all" myself -- if somebody else
does it, that is fine, though ;-).

Re: How to commit removed file?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> ...  That's a
> great news.
>
> I am not interested to make it "all" myself -- if somebody else
> does it, that is fine, though ;-).

Just in case you do not know me, sorry for too much negative
tone in my message.  I was just venting. It was not like I was
offended by something you said or anything like that.

The "commit path..." feature, while I would even agree that it
sometimes is useful in simple cases, is something that goes
quite against what git does normally, and anybody would
understand why after inspecting what git-commit has to do to
implement that.  I personally hate that "feature".

Having said that, I am known to support features that I do not
agree with myself for other people, and sometimes even implement
them myself.  But that does not mean I have to like them ;-).

Re: How to commit removed file?

[Michael S. Tsirkin]

> > ...  That's a
> > great news.
> >
> > I am not interested to make it "all" myself -- if somebody else
> > does it, that is fine, though ;-).
> 
> Just in case you do not know me, sorry for too much negative
> tone in my message.  I was just venting. It was not like I was
> offended by something you said or anything like that.
> 
> The "commit path..." feature, while I would even agree that it
> sometimes is useful in simple cases, is something that goes
> quite against what git does normally, and anybody would
> understand why after inspecting what git-commit has to do to
> implement that.  I personally hate that "feature".
> 
> Having said that, I am known to support features that I do not
> agree with myself for other people, and sometimes even implement
> them myself.  But that does not mean I have to like them ;-).

Well, it's just a minor annoyance for me, so unless more people
ask for this to be fixed, I'm unlikely to invest time in this, either.

-- 
MST

Re: How to commit removed file?

[Juergen Ruehle]

Johannes Schindelin writes:
 > On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
 > 
 > > > I'd like to remove a file and commit the removal while
 > > > leaving out other changes in repository/index.
 > > > 
 > > > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
 > > > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
 > > > 
 > > > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
 > > > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
 > > > any file(s) known to git.
 > > > Did you forget to 'git add'?
 > > > 
 > > > A similiar thing works with "git add".
 > > 
 > > Any ideas? Can this be done with git?
 > 
 > Did you actually try the "--" thing I suggested in 
 > http://article.gmane.org/gmane.comp.version-control.git/35699/?
 > 
 > Besides, I just tested with current "next": 
 > 
 > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
 > Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
 >  1 files changed, 0 insertions(+), 22 deletions(-)
 >  delete mode 100644 a234

But (at least in next from yesterday or something -- having an old
modem here only:-) it doesn't work if you delete the file using
git-rm, because git-commit -o operates only on known files: one of the
first things in this code path is a

  git-ls-files --error-unmatch -- $@

This seems wrong because -o is supposed to bypass the index. It
should probably be doing ls-tree --name-only HEAD -- $@ instead, but
ls-tree doesn't have the --error-match functionality.