pepak pepak - 1 year ago 90
Git Question

Temporarily skip a commit in submodule

Assume an existing Git-tracked module (M) with commits M1-M2-M3.

I have a Git repository for Application (A), with commits A1-A2-A3. The repository has M included as a submodule (

git submodule add URL DIRECTORY
), but it is not up to date with M - instead, it uses an older commit M1 (
subproject commit 187cac115b5f4fdeb39c25c79e882d30ee9624be

My problem is this: I want to use the contents of commit M3, but for a time I must not use commit M2. This limitation will pass eventually, but at the moment it is insurmountable. So, what are my options?

If M wasn't a submodule but rather a branch of A, it would be easy:

  1. Cherry-pick
    M3 into A3, forming A4.

  2. When the limitation on M2 passes, merge M3 into A4.

With submodule, I don't know. The only "direct" solution that I can think of involves the following steps:

  1. Create a branch B at M1.

  2. Cherry-pick
    M3 into B, forming M4.

  3. Merge B into M3, forming M5.

  4. Push M into its repository.

  5. In A, update M.

  6. In A, checkout M4.

  7. When the limitation on M2 passes, checkout M5.

However, this involves changes in M which are very much dependent on M's owner's willingness to accept them, which he has no real reason to do (as the changes don't bring anything but extra complexity to M). I would much prefer a solution where I don't have to impose on M so much.

There is an indirect solution, maybe:

  1. Create a branch B at M3.

  2. Reverse-commit
    M2 into B, forming M4.

  3. Push M into its repository.

  4. In A, update M.

  5. In A, checkout M4

  6. When the limitation on M2 passes, checkout M3.

This is much less invasive on M, which is good. However, it leaves branch B unmerged forever, which I consider a very bad situation (as I use a list of unmerged branches as a kind of "TODO list").

What's the best way of handling this situation?


Answer Source

You can avoid having unmerged branches by deleting them when you no longer need them.

I would find your first solution strange, since M5 is a merge that basically has no added value. It pollutes your version history.

What I would do is:

  1. Create a branch B at M1.
  2. Cherry-pick M3 into B, forming M4.
  3. Push B to the repository
  4. In A, checkout M4.
  5. When the limitation on M2 passes, tag M4 with old_something, push tags, and remove the branch B (also from the remote repo).

This way, the only interaction with the other guy's repo is that you create a new (temporary) branch and that he is left with a tag afterwards (no unmerged branch, but a tag. no real difference, but if you use unmerged branches for todo list, this solves your problem)

Actually, I would say that the situation with submodules is better than with branches of A. You are never polluting your version history by having unneeded merges now.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download