43

I've cloned a git submodule of one of my libraries into a project I'm working on. The thing is that, after cloning, I need to change some lines in the cloned submodule, but I don't want to push those changes into the original repository.

I want those changes to stay in the superproject. Is this possible? How can I achieve that?

EDIT: As @GoZoner said, basically its:

  1. git clone foo;
  2. cd foo;
  3. git submodule init;
  4. git submodule update;
  5. cd path/to/submodule;
  6. git checkout master;
  7. Make changes to the submodule
  8. git commit -am "Something";
  9. git push origin (the superproject);

Then when I clone the superproject in another computer (up to step 4), I want those changes to be saved, in the superproject.

AeroCross
  • 3,969
  • 3
  • 23
  • 30
  • When you say 'I want those changes to stay in the superproject' you mean: when somebody does "git clone foo; cd foo; git submodule init; git submodule update" they should have a working directory that includes my changes to the cloned submodule? – GoZoner Jun 02 '12 at 10:11
  • @GoZoner Yes - but the changes in the submodule shouldn't be pushed to its original repository. I'll restructure the question with your comment. – AeroCross Jun 03 '12 at 16:21
  • Right, that is what I thought you were asking and I don't think it is possible. Git marks the directory containing the submodule specially and won't look beyond that directory for 'local' changes. – GoZoner Jun 03 '12 at 16:51
  • Possible duplicate of [Git - how to track untracked content?](http://stackoverflow.com/questions/4161022/git-how-to-track-untracked-content) –  Jun 03 '16 at 04:24

2 Answers2

14

I think you need to relax the 'no commit to submodule' constraint. There are two options:

  1. Commit your submodule changes to a submodule branch. It is your team's branch and it is where your team put your submodule changes. When somebody clones the super project and updates the submodule they get the content of your team's branch.
  2. Clone the submodule repository 'right next to' your super project repository and initialize the submodule to point to your clone. Then when you commit changes to the submodule they are committed to your clone. Anybody who clones the super project gets submodule content from your submodule clone.

Otherwise, I don't see a way to achieve your desire.

GoZoner
  • 67,920
  • 20
  • 95
  • 145
  • 1
    These are actually nice alternatives. I can't achieve what I __actually__ want to do, but these are viable choices. What I want to do with those files is to change paths, which is basic, but still is good to know what to do in certain cases. I think I might be able to use option 2 and some difftools in the future. Thanks! – AeroCross Jun 05 '12 at 12:32
  • I don't get the meaning of 'right next to'. Could you elaborate it a bit more? Thank you. – ywu Oct 14 '20 at 20:12
  • 1
    @ywu He probably meant cloning both repositories in the same directory. – Mit94 Oct 19 '20 at 07:23
  • 1
    Thank you @Mit94 for your reply. I take it as to have a copy (clone) of the submodule repo in the super project repo and carry it around. It's not a submodule anymore, since the change for that repo in option 2 need to be saved in super project repo. – ywu Oct 19 '20 at 16:01
  • 1
    @ywu it seems pretty likely that he is suggesting that you _fork_ the submodule into your team's version control. It is still a submodule of your superproject, but the forked repo is now superproject-specific and you can change it as much as you want. This would be an alternative to creating a branch in the submodule, if your team doesn't own the submodule repo. You will still have to fight with conflicts if you want to pull updates from the master repo though. – Jon Hieb Dec 17 '20 at 05:22
  • @JonHieb Yes fork is a feasible way to go. If I understand it correctly, the forked repo is hosted somewhere else standalone and the "superproject" reference it through .gitmodules. Not sure if it's what GoZoner means since the key word "fork" is not there. – ywu Dec 25 '20 at 15:52
0

You can checkout a separate branch for your changes. Don't push that branch up. Changes that you do want to push, make that on one of the original branches. Merge that branch into your special branch that you don't push up. Don't do any other work on your special branch as you would then have to merge the other way. You can do that but it gets complicated.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 1
    If I checkout a different branch that I won't push to the original branch, then commit there, the reference will be missing when I clone the repo and init the submodule. That's what I tried before posting. A missing reference error will appear and I'd be back to square 1,unless I'm missing something. – AeroCross Jun 02 '12 at 15:32
  • You have to update your question with the exact structure. Sorry. – Adam Dymitruk Jun 02 '12 at 18:05