Re: clean bug on ignored subdirectories with no tracked files?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jay Soffian <jaysoffian@xxxxxxxxx> writes:

> git init test_repo &&
> cd test_repo &&
> mkdir -p foo/bar &&
> echo baz > foo/bar/baz &&
> echo /foo/bar > .gitignore &&
> git add .gitignore &&
> git clean -n -d
>
> Initialized empty Git repository in .../test_repo/.git/
> Would remove foo/
>
> Seems surprising.

You said "everythingthing in foo/bar is uninteresting and can be cleaned",
you have one untracked file in "foo/bar" hierarchy, and you have nothing
else in "foo/" hierarchy.

Removing the uninteresting cruft as your .gitignore instructs Git makes
the entire "foo/" hierarchy devoid of any contents. I would *expect* Git
to clean "foo" in this case.

I've seen some "surprising" behaviour in "git clean" (which I do not use
myself, I do not consider part of "my code", and I am not surprised if it
has many bugs), but I fail to see what is surprising in your transcript.

It would be a different issue if you had ">foo/other" before your "clean".
Then "foo/" has "foo/clean" that is not declared to be uninteresting.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]