Re: git rm bug

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 06 2018, Thomas Fischer wrote:

> I agree that the entire chain of empty directories should not be
> tracked, as git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/ to
> still exist.
>
> Similarly, when I run 'git rm path/to/some/file', I expect
> path/to/some/ to exist, *albeit untracked*.
>
> I do NOT expect git to *track* empty directories. But I also do NOT
> expect it to remove untracked directories.

Others have said why, but here's an edge case you probably haven't
thought of:

    (
        rm -rf /tmp/repo &&
        git init /tmp/repo &&
        cd /tmp/repo &&
        mkdir -p foo/bar/baz &&
        git status
    )

If you just have empty directories "git status" will report nothing,
although "git clean -dxfn" will show what would be cleaned up.

So if this worked as you're suggesting then someone could 'git rm" some
file, then everything would report that they're on commit XYZ, but if
they re-cloned at that commit they'd get a tree that would look
different.

No git command should behave in such a way as to leave the tree in a
state when moving from commit X->Y that you wouldn't get the same Y if
you re-cloned.