Home > Back-end >  Git: forcing `add` when file is in nested git repository
Git: forcing `add` when file is in nested git repository

Time:12-11

I would like to add a file contained into a nested git repository in the parent repository (I'm developing a library that I use in my project). However git add nested_repo/myfile does not do anything... I could try to rename the .git file when doing the commits, but then I'm afraid to have strange conflicts when I rename back the .git folder.

I know submodules is the proper way to handle nested git repositories. Unfortunately in my case I'm using git in conjunction with Overleaf (to share LaTeX documents with co-authors and edit them collaboratively in real-time) and overleaf does not handle submodules (if I try to push a project with submodules it just fails).

Any idea how I could deal with that?

CodePudding user response:

The right answer is "don't do that".

I could try to rename the .git file when doing the commits ...

This does work:

mkdir test-subdirectory
cd test-subdirectory
git init
[... output, make initial commit, etc, here]
mkdir sub && (cd sub && git init && echo echo submodule > README &&
git add README && git commit -m initial-in-sub)
[output snipped]

At this point, creating sub/file and trying to git add it does nothing, at least in the version of Git I'm using here (a year or so out of date):

git add sub/file

There is no error but sub/file is not added (nor is sub added as a submodule). But:

mv sub/.git sub/notgit
git add sub/file
mv sub/notgit sub/.git

Adding a .gitignore for sub, and git add .gitignore, and git status --short now says:

A  .gitignore
A  sub/file

but then I'm afraid to have strange conflicts when I rename back the .git folder.

It's not so much "strange conflicts", but rather the fact that the top level repository, that now contains sub/file where sub/.git exists and is a repository, now believes it has the right to create and, if necessary, destroy the directory sub and/or its contents. And indeed it does just that:

$ git commit -m 'add sub/file'
[master d6c0cb6] add sub/file
 2 files changed, 2 insertions( )
 create mode 100644 .gitignore
 create mode 100644 sub/file
$ git clean -dfx
Removing sub/README

This happens despite sub/README being a Git-controlled file in the sub Git repository:

$ (cd sub; git status --short)
$ (cd sub;git status --short)
 D README
?? file

This situation is, in a word, fraught. Don't do it.

CodePudding user response:

It's not really a solution, but it's what I end-up doing: since I have very few files to manage (actually... only one) I did a hard link of that file (symlink would not work as they are not handled the way I want) to another file in my project. I slightly modified the code to include this new file instead.

Seems to work fine so far. But keep in mind that hard link may vanish if you copy your folders somewhere else, and that it is not supported on all filesystems (e.g. FAT32).

  •  Tags:  
  • git
  • Related