Deleted folder keeps showing up?

[Benjamin Buch]

I made a branch and deleted a folder there with git rm -rf foldername.
So now i have to branches, A with the folder and B without the folder.

I'm on B, the folder is not there.
Then I check out A, the folder shows up like it should.
When I check out B again, the folder is still there.

A git rm -rf folder gives me:

fatal: pathspec 'folder/' did not match any files

, so git is not tracking the folder.

I can rm -rf the filder without git and start the whole game from the
beginning,
but there has to be a better way?

Strange enough this happens just to two folders I removed,
with others there is no problem.

-benjamin

[Michael J Gruber]

Post by Benjamin Buch
I made a branch and deleted a folder there with git rm -rf foldername.
So now i have to branches, A with the folder and B without the folder.
I'm on B, the folder is not there.
Then I check out A, the folder shows up like it should.
When I check out B again, the folder is still there.
fatal: pathspec 'folder/' did not match any files
, so git is not tracking the folder.
I can rm -rf the filder without git and start the whole game from the
beginning,
but there has to be a better way?
Strange enough this happens just to two folders I removed,
with others there is no problem.

What does "git status" say when you've checked out B? Could some
contents of folder/ possibly be being ignored (.git/info/excludes etc.)?

Michael

[Benjamin Buch]

Hi Michael,

thank you for your answer.

Strangely, I can't reproduce the error today.
As I did quite a lot branching and merging yesterday (learning git),
I can't remember the steps that led to the error.

And it doesn't have to be an error though -
perhaps it was just my clouded perception due to the lots of branches.

But I will keep an eye on this and see if it happens again.

Sorry for bothering,

- benjamin

Post by Michael J Gruber

Post by Benjamin Buch
I made a branch and deleted a folder there with git rm -rf
foldername.
So now i have to branches, A with the folder and B without the folder.
I'm on B, the folder is not there.
Then I check out A, the folder shows up like it should.
When I check out B again, the folder is still there.
fatal: pathspec 'folder/' did not match any files
, so git is not tracking the folder.
I can rm -rf the filder without git and start the whole game from the
beginning,
but there has to be a better way?
Strange enough this happens just to two folders I removed,
with others there is no problem.

What does "git status" say when you've checked out B? Could some
contents of folder/ possibly be being ignored (.git/info/excludes etc.)?
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Junio C Hamano]

Post by Benjamin Buch
Strangely, I can't reproduce the error today.

If a branch has dir/file tracked, and another branch does not have
anything tracked in dir/ directory at all, then switching from the former
branch to the latter can remove dir/ only when you do not have any
untracked files in there when you switch. Otherwise dir/ must stay
behind to keep the untracked files.

You can see it by a simple experiment.

$ rm -fr trial
$ mkdir trial
$ cd trial
$ git init
$ >elif
$ git commit -m initial
$ git branch lacksdir
$ mkdir dir
$ >dir/file
$ git add dir/file
$ git commit -m add-dir-file

Now, after this set-up, your 'master' has dir/file and 'lacksdir' does
not have anything tracked in dir/ directory.

Observe:

$ git checkout lacksdir
$ find ??*
elif
$ git checkout master
$ find ??*
dir
dir/file
elif
$ >dir/garbage
$ git checkout lacksdir
$ find ??*
dir
dir/garbage
elif

If switching to 'lacksdir' removed the dir/ directory, whatever was in the
untracked file dir/garbage will be lost. In the above exercise, I named
it garbage, so a casual reader might get a false impression that it should
be thrown away, but in real life workflow, it often happens that

(1) you start doing some interesting experimental changes, while on
'master';

(2) you realize that this change does not belong to 'master', but belongs
to some other branch, perhaps 'lacksdir';

(3) you switch to the branch, to keep working.

Remember that, in git, your uncommitted changes to the index and the work
tree do not belong to the branch. They try to follow you across branch
switching. Since untracked new files are something potentially you might
want to add after branch switching, we do not remove them. And because we
choose not to remove dir/file, even though the commit at the tip of the
lacksdir branch does not have anything tracked in dir/ directory, we
cannot remove it from the work tree.

[Benjamin Buch]

Hi Junio,

thanks for the explanation!

It made things a lot clearer for me.
And I think that could be exactly what happened
and the reason why I couldn't reproduce the 'error'.

-benjamin

Post by Junio C Hamano

Post by Benjamin Buch
Strangely, I can't reproduce the error today.

If a branch has dir/file tracked, and another branch does not have
anything tracked in dir/ directory at all, then switching from the former
branch to the latter can remove dir/ only when you do not have any
untracked files in there when you switch. Otherwise dir/ must stay
behind to keep the untracked files.
You can see it by a simple experiment.
$ rm -fr trial
$ mkdir trial
$ cd trial
$ git init
$ >elif
$ git commit -m initial
$ git branch lacksdir
$ mkdir dir
$ >dir/file
$ git add dir/file
$ git commit -m add-dir-file
Now, after this set-up, your 'master' has dir/file and 'lacksdir' does
not have anything tracked in dir/ directory.
$ git checkout lacksdir
$ find ??*
elif
$ git checkout master
$ find ??*
dir
dir/file
elif
$ >dir/garbage
$ git checkout lacksdir
$ find ??*
dir
dir/garbage
elif
If switching to 'lacksdir' removed the dir/ directory, whatever was in the
untracked file dir/garbage will be lost. In the above exercise, I named
it garbage, so a casual reader might get a false impression that it should
be thrown away, but in real life workflow, it often happens that
(1) you start doing some interesting experimental changes, while on
'master';
(2) you realize that this change does not belong to 'master', but belongs
to some other branch, perhaps 'lacksdir';
(3) you switch to the branch, to keep working.
Remember that, in git, your uncommitted changes to the index and the work
tree do not belong to the branch. They try to follow you across branch
switching. Since untracked new files are something potentially you might
want to add after branch switching, we do not remove them. And because we
choose not to remove dir/file, even though the commit at the tip of the
lacksdir branch does not have anything tracked in dir/ directory, we
cannot remove it from the work tree.
--
To unsubscribe from this list: send the line "unsubscribe git" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jeff King]

Post by Benjamin Buch
I made a branch and deleted a folder there with git rm -rf foldername.
So now i have to branches, A with the folder and B without the folder.
I'm on B, the folder is not there.
Then I check out A, the folder shows up like it should.
When I check out B again, the folder is still there.

Is there anything in the folder, like untracked files generated by your
build process? Remember that git tracks full paths, not directories. So
you never actually "deleted a folder" but rather deleted all of the
paths inside that folder.

When you switch to branch A, git creates the folder, because it contains
tracked files. When you switch back to branch B, git will remove the
tracked files, and will remove the directory _only_ if it is then empty.
Anything else would mean deleting your untracked files, which may be
precious.

You mentioned in a later email that you were having trouble reproducing
the issue. Try:

$ git checkout A
$ make ;# or whatever your build process is, or
;# normal work or whatever
$ git checkout B

and see if that reproduces it.

-Peff