2

I have a problem with git add . failing to add files. I believe (in fact, I'm sure) this is related to the fact that my local repository is located in a subdirectory of the worktree. git add --all works, but I'd like to understand what's going on here.

In the worktree directory I have two files and one repository subdirectory: ignore.txt, do-not-ignore.txt and repo. Inside worktree/repo is .git. I set git config core.worktree '/absolute/path/to/worktree'. The content of .git/info/exclude is:

   *
   !do-not-ignore.txt

When I run git status from within worktree/repo I get (with the usual message):

../do-not-ignore.txt

However, git add . does not do anything: running git status after git add . gives me the same result as above. git add --all, on the other hand, adds the file correctly. If I just move .git from worktree/repo to worktree everything works as expected.

Can someone, please, explain (or provide a link about) this behavior? Thanks.

lapk
  • 3,838
  • 1
  • 23
  • 28
  • You have a folder called `worktree` that is not your project's root directory?! Very misleading name... – jub0bs Jan 27 '15 at 20:38
  • @Jubobs I just named it `worktree` here for the sake of simplicity. Apparently, I was wrong ;). In reality, `worktree` is `/home/myuser` and `.git` is in `/home/myuser/control/repository/user/configuration/`. It's a repo for managing user configuration files. I don't want to put it in user's home directory explicitly. – lapk Jan 27 '15 at 20:45

1 Answers1

1

The . in git add . isn't a Git thing, it's a shell thing. It means "the current directory".

So when you git add . from a subdirectory, Git (rightly) only tries to add things from that subdirectory. Naturally, anything that is outside of that directory would not be included.

If you change to the true root of the repository (worktree, here), I suspect that git add . will do what you expected it to do before.

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
  • Hmm... I have a git repo in a subdirectory of user's home directory that has `core.worktree=/etc`. And `sudo git add .` works just fine there. Given that I can set `core.worktree`, doesn't `.` mean _everything in the worktree including hidden files, but excluding what is excluded (`.gitignore` and such)_? – lapk Jan 27 '15 at 21:10
  • @PetrBudnik, if it does I'd love to see a reference for that. `.` pretty much always means "the current directory", and if the Git developers have given it a different meaning they would have needed a very good reason. Certainly the standard meaning is consistent with my Git experience. http://stackoverflow.com/questions/26042390/git-add-asterisk-vs-git-add-period – ChrisGPT was on strike Jan 27 '15 at 21:16
  • [This question](http://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add) has some good discussion, particularly of differences between 1.x and 2.x behaviour. This does discuss operating on the entire worktree (even if it is not in the standard place, I think), but even here `.` seems to mean "the current directory". – ChrisGPT was on strike Jan 27 '15 at 21:22
  • Just make `source` and `repo` directories so they are on the same level (like, `~/source` and `~/repo`). Put a file in `source`. In `repo` run `git init` and set `core.worktree '/absolute/path/to/source`. In `repo` run `git status`, `git add .`, `git status`. In my experience, it works... I don't have a reference for it (as in manual). However, it does seem to work... It seems to support what I'm saying (from the accepted answer): "_The important point about "git add ." is that it looks at the working tree and..._" – lapk Jan 27 '15 at 21:22
  • @PetrBudnik, you're right, it works. I don't know why. Git seems to treat the worktree as if it were in `repo/` instead of elsewhere. – ChrisGPT was on strike Jan 27 '15 at 21:27
  • I think, it's expected behavior, because `git add .` looks in working tree. It applies `.` as `worktree/.`. Same as it applies `*` as `worktree/*`. I just don't understand why `git add .` does not work when repo is in subdirectory. – lapk Jan 27 '15 at 21:30
  • @PetrBudnik, either way it's an interesting question. I've upvoted it in the hopes that somebody with more Git knowledge than I have can answer the question authoritatively. – ChrisGPT was on strike Jan 27 '15 at 21:32
  • Thank you. And thank you for double checking the behaviour... And I hope someone will answer it. It's not a big deal if it's just that - after all, `git add --all` works. But I'm concerned that something else might be getting messed up. I also don't like how `git status` lists the files - they are listed relatively to `repo` directory (notice `../do-not-ignore.txt` in OP). – lapk Jan 27 '15 at 21:34