Re: possible bug in git apply?

david@lang.hm writes:

On Saturday 04 August 2007 2:03:59 pm Rob Landley wrote:

quoted

Signed-off-by: Rob Landley <redacted>
Amiga part Acked-by: Geert Uytterhoeven [off-list ref]

Move architecture-specific Documentation into a common subdirectory.

I really, really, really hate git.

Ok, on my laptop I just noticed that "git apply" of the patch didn't
complain but it also left the empty subdirectories it moved stuff
out of.  (I don't believe this happened on the version of git I was
using on my previous laptop, which ate itself a month and change
ago, but obviously I can't check.)

There is no "git rmdir".  "git rm" refuses to delete the directory
without -r.  "git rm -r Documentation/x86_64" listed (as just deleted) all
the files that the patch already moved out of the directory.

Am I missing something obvious here?

Committing the change?

since git doesn't track directories, only content (per the big
discussion recently) I beleive that doing a checkout would leave Rob
without the directories that he emptied out, so shouldn't git apply
also clear the directories to end up in the same state?

Yes, once he commits.  As long as git keeps files tracked in that
directory, there is no reason for it to delete it.

I agree that it is hard to come up with a good logic for this sort of
thing.  git-add checks the _current_ state of a file into the index.
git-rm can actually do the same only by actually _deleting_ the
working copy.  So when should git try deleting the directory?
Probably when the directory becomes empty in the index, for
consistency.  Too bad that the index does not contain any information
about directories at all, so there is no good way to figure this
particular point in time out efficiently.

I guess that git rather attempts deleting the directory when the tree
in the _repository_ rather than the index becomes empty.  And for that
you need to commit.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum