On Wednesday 2006, November 29 16:03, Martin Waitz wrote: > The way I wanted to address this is to show in the supermodule > git-status that the submodule is using another branch. > That way you are warned and can decide not to commit the supermodule. The problem I see with tracking a particular branch is that it makes it less convenient to use git's quick-branching features in the submodules. Let's say I want to try something out quickly in a submodule, I make a branch, commit, commit, "hmm, looks good, let's snapshot it in the supermodule", make a supermodule branch, "oh no, I've got to tell the supermodule to track the new (but temporary) branch in the submodule do a commit, switch the submodule branch back to master, delete the temporary branch, remember that the supermodule is tracking that branch and tell the supermodule to track something else instead... It all seems too complicated to me. > Pro HEAD: > - update-index on submodule really updates the supermodule index with > a commit that resembles the working directory. Ouch. Why does the submodule need to update the supermodule index? That should be done by update-index in the supermodule. Further, how is the supermodule index going to represent working directory changes in the submodule? The only link between the two is a commit hash. It has to be like that otherwise you haven't made a supermodule-submodule, you've just made one super-repository. Also, if you don't store submodule commit hashes, then there is no way to guarantee that you're going to be able get back the state of the submodule again. > Contra HEAD: > - HEAD is not garanteed to be equal to the working directory anyway, > you may have uncommitted changes. That's the case for every file in a repository, so isn't really a worry. It's the equivalent of changing a file and not updating the index - who cares? As long as update-index tells you that the submodule is dirty and what to do to clean it, everything is great. > - when updating the supermodule, you have to take care that your > submodules are on the right branch. > You might for example have some testing-throwawy branch in one > submodule and don't want to merge it with other changes yet. What is the "right" branch though? As I said above, if you're tracking one branch in the submodule then you've effectively locked that submodule to that branch for all supermodule uses. Or you've made yourself a big rod to beat yourself with everytime you want to do some development on an "off" branch on the submodule. > Pro refs/heads/master: > - the supermodule really tracks one defined branch of development. Why is this a pro? > - you can easily overwrite one submodule by changing to another branch, > without fearing that changes in the supermodule change anything > there. You can always do that anyway by simply not running update-index for the submodule in the supermodule. > Contra refs/heads/master: > - after updating the supermodule, you may not have the correct working > directory checked out everywhere, because some submodules may be on a > different branch. This seems like the biggest problem to me - doesn't this negate all the advantages of a submodule system? After a check in, you have no idea if what you checked in was what was in your working tree. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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