2

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!

MarcM
  • 2,173
  • 22
  • 32
JOINSO
  • 43
  • 5
  • 1
    The contents of B will _always_ be what you have in the revision when you make it. So, your revision is what it is. What git is basically asking you to do is to get the changes made on B... that is normally done with a merge, but other techniques can be used. Is there a reason why you don't want to merge? – eftshift0 Oct 08 '21 at 04:43
  • By the way, it's not about contents of files that git checks to reject. It's revisions. There are revisions in the remote that you don't have in your branch. That is what git is telling you. – eftshift0 Oct 08 '21 at 04:46
  • The reason that I do not what to merge, is that do not need to work with B. 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. – JOINSO Oct 08 '21 at 05:27
  • Given that files in `B/` are *in the repository*, you *must work with them*. Even if you never check them out (by using Git's "sparse checkout" mode) you will still be working with them: you just won't ever *see* them, as you work with them. They will be invisibly in Git. – torek Oct 08 '21 at 06:46
  • I suggest you to take a look at https://stackoverflow.com/questions/46905373/git-push-only-one-folder – MarcM Oct 08 '21 at 08:28

2 Answers2

2

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.
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for your answer. After this changes , people working on B, needs to do changes before doing next commit/push? – JOINSO Oct 08 '21 at 07:17
  • @JOINSO People working on B, if they need A, need to update A, to check their B code they are about to push does work with the latest pushed A. – VonC Oct 08 '21 at 07:27
  • And what about the "exclude" or skip-worktree options? – JOINSO Oct 08 '21 at 07:37
  • @JOINSO As long as A and B are part of the same repository, you will have the same issue. – VonC Oct 08 '21 at 07:45
0

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.

LeGEC
  • 46,477
  • 5
  • 57
  • 104