can anybody explain the following to a git noob?

A transcript...

git init git add . > /dev/nul git commit -m 'initial import'

git status # On branch master nothing to commit (working directory clean)

***** Create new branch ******** git checkout -b my_branch Switched to a new branch "my_branch"

*********Try to rename a directory WTF?: Git thinks any directory with a .git folder is empty and refuses to rename the directory. git mv vendor vendor_new fatal: source directory is empty, source=vendor/plugins/acts_as_audited, destination=vendor_new/plugins/acts_as_audited

ls vendor/plugins/acts_as_audited/ CHANGELOG generators init.rb lib LICENSE Rakefile README spec tasks test.txt

******** Initial state of the test directory ls test fixtures functional integration mocks test_helper.rb unit watir

****** Rename and commit changes git mv test test_new git commit -m 'renamed the test directory'

********Current state of the directory
 ls
app  Capfile  config  db  doc  lib  MyProject.kpf  public  Rakefile  README
script  test_new  tmp  vendor

********Checkout master. WTF?: Both the test and the test_new directories exist. Why does the test_new exist in this branch? git checkout master ls app Capfile config db doc lib MyProject.kpf public Rakefile README script test test_new tmp vendor

******** list  the test directory.  WTF?: Where did the mocks subdir go??
(see above for the initial directory listing)
 ls test
fixtures  functional  integration  test_helper.rb  unit  watir

**** Check the test_new directory: WTF?: Where are all the other subdirectories? ls test_new functional mocks

******** Merge Everything is merged properly. git merge my_branch

ls app Capfile config db doc lib MyProject.kpf public Rakefile README script test_new tmp vendor ls test_new fixtures functional integration mocks test_helper.rb unit watir

obviously I am doing something profoundly wrong. Can somebody explain why this is happening?

On Thu, May 21, 2009 at 11:46 PM, Tim Uckun <timuckun@gmail.com> wrote:

...okay...

Well, why do other folders contain .git directories? Are they *separate* git repositories? If so, git doesn't know what to do with them and leaves them alone. (Well, in fact it treats them as submodules.)

All your other weird problems seem to come from this, as far as I can tell. If not, it would be helpful if you could give *complete* reproduction steps for your problem.

Have fun,

Avery

It just worked out that way. I am experimenting with a rails app and those plugins were pulled from github.

yes they are separate repositories. I would be happy if it left them alone or treated them as submodules. I was just puzzled as to why git thought they were empty when they were clearly not.

Those were the complete steps. I did no other operations on the directory. So the fact that the test directory is misbehaving is because a directory in the vendor hierarchy has a .git folder?

I'll have to clean up all those and see if the problem remains.

Tim Uckun wrote:

But not, I take it, as submodules?

Because from git's point of view, they were already managed in a separate repository as a submodule. When you have submodules in a repository, the parent repository can't (well, won't anyways) track files inside the submodule directory, so git ignores everything under a worktree subdirectory that contains a .git folder.

A better way is probably to import those projects as proper submodules so you can update them without hassle later. "git help submodule" should get you a long way, but be prepared to study the docs a little so you understand the caveats with submodules before you use them. For instance, you *will* run into problems if you later replace a worktree subdirectory belonging to the parent git repository with a submodule, so it's really better to have them as submodules from the start.

HTH

That's right.

I deleted the .git directory in that subfolder but I got the exact same message. There was a .gitignore file in there so I deleted that too and still got the same message. I think since the initial checkin has the .git folder in it git has already decided it's not going to track it.

Anyway as you can see from my original post I decided to mv the 'test' directory instead because it has no .git directory in it.

To be honest I am just trying to learn the basics now and would rather get comfortable with those before I mess around with submodules.

I still don't have an answer as to why the renamed test_new directory exists master branch and why both the original 'test' directory and the renamed 'test_new' directory are missing subdirectories.

Until I understand that I won't feel comfortable using git.

Tim Uckun schrieb:

Did test_new contain ignored files? In this case, when you checkout the branch that does not have test_new, only the tracked files are removed; the ignored (i.e untracked) files remain. Therefore, after the checkout you still have a test_new directory.

-- Hannes

No. I put the entire transcript in the first email. I did not tell git to ignore anything and there were no .git directories in the test folder.

As far as I can tell all the files are tracked after I do a commit.

I can understand why it put the original test directory back when I changed to the master branch but I don't understand why it's missing a subdirectory. I don't think the test_new directory should be in the master branch at all but I guess I can kind of sort of see why git might not remove it. What I can't understand at all is why it's missing subdirectories.

I hate to say this but I tried the exact same thing with mercurial in the last half hour and it did exactly what I thought it should do. The master had the test directory but not the test_new and the branch had the test_new directory but not the test. No subdirectories were missing out of either one.

On Fri, 22 May 2009, Tim Uckun wrote:

What's in the subdirectory? Is it empty? If so, that would explain what you are seeing. Git doesn't track directories - so an empty directory is always treated as an untracked file.

I don't know if mercurial tracks directories, if it does, then this would explain why it behaves diffently to git.

The directories are not empty. They contain various tests (unit tests, integration tests etc).

That might be the reason.

I am just baffled. I have run that script many times and it always turns out the same. For example on one run I removed all the .git directories in all the subdirectories to see if I would get different results but it didn't help (git mv worked but the messed up directories remained).

I also tried renaming other directories and similar things happen.

Tim Uckun wrote:

No you did not. You used 'ls' where you should have used 'ls -a' to also show the "hidden" directory entries (.gitignore and .git)

But the upstream project could well have told git to ignore stuff, and since .gitignore files are transmitted on clone they would have been sent along to you.

"git ls-tree -r --name-only HEAD" will show you all the tracked files. You'll almost certainly want to pipe it through less or some such.

Try "git ls-tree -r --name-only | grep gitignore" to see all the .gitignore files.

Because that subdirectory was never tracked by git. If it had been, it would have been there when you switched branches.

Naturally, since mercurial (rightly) ignores .gitignore files and the .git/ directory. With mercurial though, you're not only tracking the history of the files, but also the history of the object databases of all the git repositories you've cloned and that live in subdirectories of your master-project. Whether or not that's an actual problem for you is something you'll have to decide for yourself. If you want to keep that exceptionally odd configuration, please remember to never run "git repack -a" in the subdirectories originating from github clones, or mercurial will think files have gone missing.

On Fri, 22 May 2009, Tim Uckun wrote:

Obviously, there's more before the transcript started; otherwise, there would be nothing to import in the initial commit, and there certainly wouldn't be .git directories that came from nowhere. I don't think any version control system I know of likes having your initial import be of a directory with other working directories for the same system as subdirectories. (That is, Mercurial will be fine having git working directories in the import, but git won't, and Mercurial wouldn't be happy about having Mercurial working directories as subdirectories).

This tends to happen if, while on a different branch, you editted some files and left editor backups or compiled (maybe just-in-time) files in that directory. Then there are files in the directory that don't belong to any branch, since they're not source files.

It's also highly likely that what's missing is stuff you thought you imported initially, but did not actually import due to the confusion with it already being a git working directory.

	-Daniel
*This .sig left intentionally blank*

Sorry. The command before git init is svn export  blah/blah/blah/

I am taking a rails project and putting it under git. The .git files are there in the pluging because the plugins are hosted on github and they ware installed via git clone.

I know people keep mentioning those directories so I want to repeat myself. I renamed the test directory which had no .git folders anywhere in them. It contains the tests for the rails project and nothing else.

I now realize that. I did however did the same thing again but first deleted all the .git directories before doing a git init. The end result didn't change.

I now understand that this is the way git works. I wasn't expecting this though. I was exptecting the master branch to look like it was before I switched to another branch and mucked around.

As I said in a previous email mercurial worked as I was expecting. Subversion also works the way I expected. Coming from subversion I never expected git to carry the new directory name into the original branch.

The way I have always thought about branches was that they are isolated from other branches and it surprised me greatly when git "leaked" the new directory from the "my_branch" branch into master.

I still kind of think I did something wrong. This behavior seems extremely odd to me.

I didn't edit any files. I didn't compile anything. There should have been on artifacts of any sort. I did a commit before switching branches.

As I said the test directories did not have any .git directories in them. If they had git mv would not have worked.

On Sat, May 23, 2009 at 08:21:09PM +1200, Tim Uckun wrote:

Note that a second git init does not delete the previous database. So if you want to start from scratch you need to delete the main .git folder.

As already mentioned a script recreating your setup from public sources would really be a big help to find out were git does not do what you are expecting.

cheers Heiko

Yes of course.

OK. I'll give that a shot.

I would still like to know what went wrong with my own sources though.
 After all I am going to be using it with my own sources.

On 2009-05-22, Tim Uckun <timuckun@gmail.com> wrote:

I believe those look like submodule directories to git, which are handled quite differently.

man git-submodule maybe a good starting point

It would be nice if instead of a transcript, you provided us with a script that duplicated your problem instead of having everyone on the git-list play 20 questions.

In any case, I'm going to try and explain what's going on.

On 22/05/09 15:46 +1200, Tim Uckun wrote:

Try reading `man git-mv`. "...it renames <source>, which must exist...".

What was this `ls` for? Also, next time try doing `ls -a` so people know what hidden files exist.

Again, `ls -a`.

Where is `git add .`?? Additionally, you must specific the `-a` flag on `git commit` to apply the commit to files you removed.

This is because you didn't commit the deletion of test. I can't speak to anything else. It's like telling you to change your tires when the engine has disintegrated.

Best, Dan