<feed xmlns='http://www.w3.org/2005/Atom'>
<title>git/git-rm.sh, branch master</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/git/git.git/
</subtitle>
<id>https://git.shady.money/git/atom?h=master</id>
<link rel='self' href='https://git.shady.money/git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/'/>
<updated>2006-05-20T00:28:33Z</updated>
<entry>
<title>Add builtin "git rm" command</title>
<updated>2006-05-20T00:28:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@osdl.org</email>
</author>
<published>2006-05-19T23:19:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=d9b814cc97f16daac06566a5340121c446136d22'/>
<id>urn:sha1:d9b814cc97f16daac06566a5340121c446136d22</id>
<content type='text'>
This changes semantics very subtly, because it adds a new atomicity
guarantee.

In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.

This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.

So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.

This is only an issue with "-f", of course.

I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).

The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?

Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>git-rm: Fix to properly handle files with spaces, tabs, newlines, etc.</title>
<updated>2006-02-23T01:10:42Z</updated>
<author>
<name>Carl Worth</name>
<email>cworth@cworth.org</email>
</author>
<published>2006-02-23T00:37:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=3844cdc8f19dcd848003586d6b98c9f2bd36a7d0'/>
<id>urn:sha1:3844cdc8f19dcd848003586d6b98c9f2bd36a7d0</id>
<content type='text'>
New tests are added to the git-rm test case to cover this as well.

Signed-off-by: Carl Worth &lt;cworth@cworth.org&gt;
Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
<entry>
<title>Add new git-rm command with documentation</title>
<updated>2006-02-23T01:10:42Z</updated>
<author>
<name>Carl Worth</name>
<email>cworth@cworth.org</email>
</author>
<published>2006-02-21T23:04:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/git/commit/?id=d4a1cab541be0c276b38285c8b33050ea411eacf'/>
<id>urn:sha1:d4a1cab541be0c276b38285c8b33050ea411eacf</id>
<content type='text'>
This adds a git-rm command which provides convenience similar to
git-add, (and a bit more since it takes care of the rm as well if
given -f).

Like git-add, git-rm expands the given path names through
git-ls-files. This means it only acts on files listed in the
index. And it does act recursively on directories by default, (no -r
needed as in the case of rm itself). When it recurses, it does not
remove empty directories that are left behind.

Signed-off-by: Junio C Hamano &lt;junkio@cox.net&gt;
</content>
</entry>
</feed>
