On Tuesday 22 June 2010, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > True, but as I've argued above, I'm not sure that adding another > > setting (aka. .merge_branch) for this special/limited kind of > > branch tracking is worth it. > > I don't think .merge_branch is necessary nor even desired. Good. > In fact, > I think your use of .branch, especially in the variant that does not > have any submodule entry in the superproject tree, of your version > (B) does not have conceptual advantage. You checkout the > superproject first (which would be the natural thing to do, as you > may get update to its .gitmodules there), and checkout the then-tip > of the named branch of the submodule, you would immediately get a > stale checkout when you then go fetch the updates to the submodule. Not if the initial checkout of the submodule included an implicit fetch/pull within the submodule (exact behaviour probably to be controlled with some config). > And the worst part is that you wouldn't even _notice_ that your > checkout is stale, as there is no record in the superproject which > commit you were supposed to be using to be consistent with the > version the committer of the superproject commit used to record it. The idea (in B.1.) is that if you _truly_ don't care which version of the submodule you're checking out, then there should be no submodule entry in the superproject that would "pollute" your status/diffs. Note that I'm not in this camp myself, as I would very much like to keep track of where my submodule is (and has been) checked out. So I'll stop trying to argue for a use case that I'm not going to use. At the time, it seemed like a logical conclusion of the tracking-submodule-branches debate, but if it's not going to be used in practice, there's no point in keeping it alive. > I on the other hand think what you called "hybrid" makes sense (and I > don't even think it is hybrid but rather is a natural way to do > this). Agreed. I too believe that the "hybrid" is much more useful in practice than the extreme version (without a gitlink entry in the superproject). But I also believe that Git shouldn't enforce specific workflows, so that if people actually want to track submodule branches in the non-"hybrid" (haphazard) manner, then Git should not stand in their way. On the other hand, if nobody's gonna do this, there's no point in implementing support for it. > With the submodule.*.branch entry, you can: > > - make sure that your checkout is consistent; if your submodule > checks out a different commit or branch from what the superproject > records in its tree or in its .gitmodules (e.g. you forgot to update > the submodule when you switched superproject branch), git can notice > the situation and can help you implement policy decisions; > > - record a commit that is different from the tip of the submodule > branch when making a superproject commit; git can notice the > situation and can help you implement policy decisions (e.g. you could > choose to reject and tell the user to advance the submodule branch > first before making the commit in the superproject); > > - use it as an advisory "existing merge commit selector", as > discussed in this thread. Ah, I see. IINM you indeed prefer to use the same setting (aka. submodule.<name>.branch) for controlling both the merging of submodules (as discussed in this thread), and the other aspects of the submodule branch tracking feature. We agree here. However, it seems you would like the .branch setting to be more advisory in nature: Instead of blindly checking out whatever .branch specifies, you'd rather have a more careful interplay where the .branch option should only check whether it is consistent with what happens to be checked out in the submodule, and warn when this is not the case. This may be better than what I suggested, but it's hard to say anything for sure until the various alternatives are tested in practice. > Thinking about what would happen in your (B) that doesn't record the > exact commit, I think that it doesn't have any advantage over the > "hybrid" one. The "hybrid" one can help you to make sure that what > you commit in the superproject's .gitmodules and submodule's branch > tip are kept consistent. When they are kept consistent, then > switching branches in the superproject should always flip between the > tips of branches, no? Yes, if branch "foo" in the superproject records "branch = subfoo" in .gitmodules, and the current tip of "subfoo" as a gitlink, and branch "bar" in the superproject records "branch = subbar" in .gitmodules and the current tip of "subbar" as a gitlink, then, indeed, switching between these two branches should auto-flip between the branch tips. One of the remaining questions is what happens when the superproject does not change, but commits are added to the submodule branches. Now, when switching between branches in the superproject, should Git: 1. Do nothing (this is the current behaviour, the user is forced to 'git submodule update' after 'git checkout' in the superproject) 2. Only checkout the recorded gitlink (this defeats the purpose of branch-tracking, IMO) 3. Checkout the recorded gitlink, but warn about the updated branch tip (a valid behaviour IMO) 4. Checkout the updated branch tip of the submodule, and warn about the out-of-date gitlink entry (also a valid behaviour IMO) 5. Checkout the updated branch tip AND stage a new gitlink in the superproject (this is a bit to "magic", IMO) ...Johan -- Johan Herland, <jherland@xxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html