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 onlyA
- 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
.