Re: git rm bug

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 6, 2018, 22:50 UTC
Message-ID: <87bmcnzg0l.fsf@evledraar.gmail.com>
In-Reply-To: <1528314421.2665575.1398886712.579F37CE@webmail.messagingengine.com>

On Wed, Jun 06 2018, Thomas Fischer wrote:

Show 11 quoted lines

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