0

I have a repo that ignores everything except a few files and the .gitignore looks like this:

# first ignore everything
*

# then whitelist what's needed
!*/
!.gitignore
!wordpress/wp-content/plugins/check-last-login/*
!wordpress/wp-content/plugins/wp-issuetracker/*
!mediawiki/extensions/single-signon/*

This repository is a child repository. It is inside of another repository, the parent. The child repository is ignoring everything except the few things just fine, but the parent is also doing the same, but I don't want it to.

It seems like the parent repo follows the ignore rules of the child repo's .gitignore file. I tried .gitignoring the .gitignore file of the child repo but that didn't work in making the parent track all files.

How can I make the parent not ignore any of the files that the child ignores?

trusktr
  • 44,284
  • 53
  • 191
  • 263
  • Submodule repos are independent entities. What's in the submodule repo is in that repo, not the parent. – jthill May 15 '14 at 15:42
  • @jthill @jthill Well interestingly, I removed the `.gitignore` and put those rules in `.git/info/exclude`, and now the parent repo completely ignores the subrepo so i can commit everything in the subrepo to the parent repo. When I clone the parent repo, the clone does not include the submodule's `.git` folder, which actually turns out to be good, since i push the parent to a totally different place than where i push the submodule (one to github, and the other to my server). So by moving the rules to the other file, it somehow worked out. I'm not entirely sure why though. – trusktr May 15 '14 at 17:34
  • 1
    I confess I don't understand this setup at all. Do you have content committed to _both_ repositories then? And, if so, how are you getting the parent repository to ignore the nested `.git`? – jthill May 15 '14 at 19:40
  • @jthill Yep, the parent has all files committed while the sub repo has only the non-ignored files committed. The thing is, I've no idea why the parent ignores the subrepo .git folder. If I find out I will definitely post back. – trusktr May 15 '14 at 21:33
  • It's odd because i *do* remember parent repos tracking sub repos in other cases, where subrepo changes had to be committed in the subrepos before being able to commit those changes in the parent. So my current case is new behavior i haven't seen before. – trusktr May 15 '14 at 21:44

1 Answers1

0

Okay, I can make git do this the obvious way, by doing git init in a directory that already has tracked content, and the smoketests all work. I certainly wasn't expecting that. git's apparently following existing trees (the repo objects) into the submodule:

   # in a throwaway clone of an existing project
   git init src
   cd src
   mkdir -p .git/info
   echo "*.junk" >.git/info/exclude
   touch foo.junk; git add .; git commit -m-
   git ls-files -s
   cd ..
   git add src
   git ls-files -s src

and I've got parallel histories. That actually makes at least some sense; it usually doesn't care at all about files that aren't tracked, and git add has to ignore .git in the root tree. For what concrete reason should git refuse to do this? I can't think of one offhand.

I'd be mildly worried that someone will perhaps rather arbitrarily decide this behavior's a bug and make git start checking for .gits on the way down, but thinking about it I think hardcoding ignore-.git-even-in-subtrees rather than only in the root might even be intentional. It might leave you with some handroll synchronization if you ever start collaborating with other repos rather than just publishing, but writing the scripts to do it seems straightforward at first glance, and you're plainly getting some value out of the setup. <shrug>.

As you've discovered, repo-local excludes go in .git/info/exclude.

jthill
  • 55,082
  • 5
  • 77
  • 137