Please add an easy way to switch between tracking and bound to a commit

[eddyp]

Don't know if this is the right place to report this, but I know you took care of some git submodule improvements, so I am hoping this reaches the right people, so here goes.

It would be really useful if in an existing repository with a submodule could be easily switched back and forth to track a branch or a specific commit in the submodule.

The obvious use case would be: * a super-project with several modules maintained by the same team * during the development cycle the modules are all in tracking mode * just before the release, the dependencies are frozen, so the submodules are switched to a specific version * the release tag is applied on the super-project (with all submodules bound to specific commits) * after release the submodules are switched back to tracking mode

In order to make this use case possible, git submodule must have an easy way to switch back and forth between tracking and "frozen".

[jlehmann]

Am 28.03.2015 um 18:43 schrieb eddyp:

Don't know if this is the right place to report this, but I know you took care to git submodule improvements, so I am hoping this reaches the right people, so here goes.

That's ok (even though asking this on the git mailing list will make it reach more people that just me ;-).

It would be really useful if in an existing repository with a submodule could be easily switched back and forth to track a branch or a specific commit in the submodule.

The obvious use case would be:

• a super-project with several modules maintained by the same team
• during the development cycle the modules are all in tracking mode
• just before the release, the dependencies are frozen, so the submodules are switched to a specific version
• the release tag is applied on the super-project (with all submodules bound to specific commits)
• after release the submodules are switched back to tracking mode

In order to make this use case possible, |git submodule| must have an easy way to switch back and forth between tracking and "frozen".

I assume by "tracking mode" you mean "git submodule update --remote"? Then it should be as easy as using "--remote" while intending to track the remote branch. Freezing the dependencies would mean to commit and then push the new submodule state in the superproject. Everybody who wants to follow this specific version then just drops "--remote" from the update command until he wants to enter tracking mode again.

Does that make sense?

[eddyp]

I assume by "tracking mode" you mean "git submodule update --remote"?

Yes, or something even less restrictive than the current model.

One of the problems I see is that even if using "git submodule update --remote", the behaviour is not exactly suitable for modules maintained by the same team, mainly because after an update the branch of the submodule is detached af any commit happened locally (even with push) on that submodule.

I would expect that after the following sequence, the submodules for Bob and Alice would be on the local master branches (as opposed to latest commit or some other state):

1. Bob and Alice have a superrepo S with submodule M tracking the remote 'master' branch (under D directory)
2. Bob does a fresh clone of S and a (magic) update submodule command; the result is that:
   1. D is now updated to match master on the remote branch, and
   2. locally M is on the local master branch
3. Bob sees some changes to be done in M, makes his changes and from D does a commit and push
4. if Bob goes in S and tries a submodule update command nothing changes for him, since his M/origin/master ref is updated
5. Alice already had a S clone (including the M module) and had the version before Bob's change
   1. When Alice updates she would see the latest changes from Bob and, assuming a clean local M master branch and checkout in Alice's local M repo, on submodule update everything should be identical in Alice's repo as is in Bob's and
   2. in M, local master is checked out (and it points to the same commit as origin/master - Bob's commit)

Currently 1.ii is not respected, and, even worse, 4. makes M to be brought back to the detached commit before Bob's changes. (In my view, it is semi-frozen, until somebody does a commit in the S repo after puling in Bob's new changes in the M repo under D.)

Note: I understand 5.i and 5.ii are a little more difficult dues to possible merge issues, so it could be postponed until a workable sane default can be implemented.

Then it should be as easy as using "--remote" while intending to track the remote branch. Freezing the dependencies would mean to commit and then push the new submodule state in the superproject.

This is not ideal, mainly because of the detached head issue.

Everybody who wants to follow this specific version then just drops "--remote" from the update command until he wants to enter tracking mode again. Does that make sense?

I think just after checkout git should be able to detect in which mode a specific submodule is in, by default and it would be better if git could figure out in which mode the repo is after checkout.

I guess I think changing from tracking to frozen should be a versioned commit itself somehow, so that on the next update (with default parameters) everybody is on the current working mode, no matter what they did locally.

[stefanbeller]

branch of the submodule is detached af any commit happened locally (even with push) on that submodule.

I consider to send patches such that submodules can be configured to be on a branch by default, i.e. if the sha1 of the submodule as recorded in the superproject matches the sha1 of the branch (the branch as recorded in the superproject) in the submodule, Git ought to checkout the branch instead.

If these two sha1's differ, we could either abort, detach head or even reset the branch to the recorded sha1.