3

I need two connected (forked) repositories to have a common folder whose contents are not considered when synchronizing the two repositories (both directions). In such a way where this requires no manual intervention when synchronizing to prevent accidental overwrites/merges/adds.

More details:

Consider repository A (private) and fork F (public). In each repository there is a folder /myprecious.

In repository A the myprecious folder contains lots of files and is actively worked on and needs to be part of the repository. In fork F the same folder only contains a subset of the files (placeholders) which normally won't be modified.

When receiving a pull request from fork F, the myprecious folder should be left intact, nothing added, deleted or modified. Likewise when fetching A's changes into fork F the myprecious folder's changes and additions should not be received but ignored.

Is it perhaps possible to include myprecious in repo A via submodule (ie move the folder's contents its own repository), while removing the submodule link in fork F, replacing it with different (non-submodule) content? Will this work without merge conflicts? Or is there a better, easier way to set this up?

CodeSmile
  • 64,284
  • 20
  • 132
  • 217
  • From your description, it sounds like submodule is what you are looking for. – Anas Alkhatib Aug 20 '13 at 17:27
  • I may be overthinking this. Perhaps if I start out with the public repo F and from that fork the private repo A I only need a way to prevent the myprecious folder's changes from being included in pull requests. Hmmm... – CodeSmile Aug 20 '13 at 18:08
  • this seems to be a possible solution: http://stackoverflow.com/questions/6138076/git-assume-unchanged-vs-skip-worktree (I didn't know .gitignore could be added to any folder, not just the root) – CodeSmile Aug 20 '13 at 18:15

1 Answers1

1

From your description, it sounds like submodule is what you are looking for. It would involve some extra steps. When forking, you would need to also init submodules and get the latest commited files. Maybe two branches would need to be maintained one to be pushed so anyone who forks it will get those changes in the submodule and another local branch with the extra files.

Adding more details:

So this is how it would work:

  • Create git repo myprecious.
  • In repo A, add the submodule myprecious.
  • In the myprecious directory Add the stub files and commit those changes in the submodule
  • When you leave the myprecious directory, you see changes to your submodule.
  • Add those changes as a commit in A. and share with the world.

Now when someone forks repo A, if they do:

git submodule init
git submodule update

They will get the submodule updated with the stub files.

Now for your local changes:

  • If you make any changes in Repo A within the submodule
  • you can commit them and push them back to repo submodule.
  • But as long as you don't commit the changed submodule in repo A, people who fork repo A won't get any of those changes.

Alternative if not submodules:

If the local changes done in A/myprecious are not to be tracked/commited, you could look at using:

git update-index --assume-unchanged <files>

See: http://blog.pagebakers.nl/2009/01/29/git-ignoring-changes-in-tracked-files/

Anas Alkhatib
  • 1,110
  • 1
  • 9
  • 22
  • The myprecious changes *must* be tracked and committed to repo A but not transferred to the public repo F. – CodeSmile Aug 20 '13 at 17:53
  • Yeah, then sounds like submodules would do what you need. – Anas Alkhatib Aug 20 '13 at 17:59
  • Oh ... I think I get it. Since submodules are not synched automatically, and the linked submodule is a private repository, the public fork can't even sync it. Still, there's the problem that there **have** to be certain stub files in that folder when the submodule isn't synched for the project to work (ie not reporting missing files etc). – CodeSmile Aug 20 '13 at 18:44
  • Added more details above. Let me know if something is not clear. – Anas Alkhatib Aug 20 '13 at 20:27
  • Thanks this is helpful. But I or someone else is definitely going to commit the submodule to repo A, while users of fork F would have to deal with the submodule issues (ie not synched automatically) which is what I want to avoid. I probably shouldn't fork the project after all, instead set up repo A as a separate, unlinked repository and merge changes that should go in F locally in my working dir of F ... and vice versa. – CodeSmile Aug 20 '13 at 20:39