Home > Mobile >  Git. Ignore files when push does not take care of .git/info/exclude
Git. Ignore files when push does not take care of .git/info/exclude

Time:10-08

I have a repo with this structure:

/github_folder
|_A
|_B

So there are two folders: A and B

I only work in folder A. The other people of the team works in folder B.

I start to work. I make a pull, make changes and then make a commit, and push. Everything is ok. This is made by an automatic process that generates the new files in folder A.

The problem comes when another person makes a push to the repo with changes in folder B when my automatic process is not ended and tries to do the push. It says that I have local changes that are different from the repo.

This is the normal behaviour of git.

To avoid this, I try to use .git/info/exclude with this content:

B/

But the problem still remains.

So I tried this before doing the push:

git update-index --skip-worktree <FILE>

for every file in folder B.

But the problem persists.

Also if I do this:

git check-ignore <FILE_INSIDE_B>

I get an empty response.

Doing this:

git rm --cached <FILE>

Is not a solution, because it will remove the file on the repo.

So, the big question is:

How to keep the content of the folder B in the repo when doing a push?

Thanks!

CodePudding user response:

Some persons tells me that perhaps a solution is work with 2 repositories: one for folder A and another for B, but this not good for people working in B that also needs to only read contents in A.

That would still be the recommended approach:

  • main repository, in which you declare A and B as submodule, with A and B being their own repository, using git filter-repo.
  • each submodule is set to track the main branch
  • you can work in A, and push only A
  • you can read B since the parent repository would check out both A and B submodule repositories.

CodePudding user response:

If the modifications you want to push to A/ depend on the content of B/ (e.g : if the generated files you mention take some files in B/ as an input), then you will need to update the content of B/, and start your generation again.


If you know for a fact that your process doesn't depend on B/ at all, then you can simply update the B/ part before pushing.

You can do this either by merging with the updated work :

git fetch origin
git merge origin/mainbranch

or by rebasing your work on top of the updated remote :

git fetch origin
git pull origin/mainbranch

If your local branch is set to track origin/mainbranch, the first one is equivalent to git pull, the second one to git pull --rebase.
You can also set git config pull.rebase true to have git pull always behave as git pull --rebase.

  • Related