views:

885

answers:

3

I have a project using Git where I've branched off of master to rename a directory.

The rename in the branch works as expected. When I switch back to the master branch the directory has its original name, but there's also an empty directory tree with the name that I changed it to in the branch.

Is this the expected behavior? Am I missing a step?
Do I just need to delete these empty directory trees as they appear?

I know Git doesn't track empty directories and that may be a factor here.

My current workflow is:

# create and checkout a branch from master
/projects/demo (master)
$ git checkout -b rename_dir

# update paths in any affected files

# perform the rename
/projects/demo (rename_dir)
$ git mv old_dir new_dir

# add the modified files
/projects/demo (rename_dir)
$ git add -u

# commit the changes
/projects/demo (rename_dir)
$ git commit -m 'Rename old_dir to new_dir'

I get to this point and everything is as expected:

# old_dir has been renamed new_dir
/projects/demo (rename_dir)
$ ls
new_dir

The issue comes when I switch back to master:

/projects/demo (rename_dir)
$ git checkout master

# master contains old_dir as expected but it also
# includes the empty directory tree for new_dir
/projects/demo (master)
$ ls
old_dir new_dir

new_dir is an empty directory tree, so git won't track it - but it's ugly to have there.

+6  A: 

Yes, you can remove it. You can also use git clean -d to remove the directory.

Rob Di Marco
Thanks - that's a useful command I wasn't aware of.
jmohr
A: 

FWIW, I don't get that behaviour with 1.6.3.1: new_dir has disappeared after final checkout of master.

Which version are you using?

Steve Folly
I'm using msysgit 1.6.4
jmohr
Are there any hidden untracked .* files in new_dir?
Steve Folly
A: 

It's rather likely that you have hidden files in the new directory. "ls -a newdir"

apenwarr