"W. Trevor King" <wking@xxxxxxxxxx> writes: >> From what I have heard of projects using this: They usually still have >> something that records the SHA1s on a regular basis. Thinking further, >> why not record them in git? We could add an option to update which >> creates such a commit. > > I think it's best to have users craft their own commit messages > explaining why the branch was updated. That said, an auto-generated > hint (a la "git merge") would probably be a useful extra feature. I am not quite sure I agree. When the project says "Use the tip of 'bar' branch for the submodule 'foo'" at the top-level, does an individual user who is not working on the submodule 'foo' but merely is using it have any clue as to why the submodule's 'foo' branch 'foo' moved, or does he necessarily even care? For such a user working at the top-level superproject, or working on one part of the project, possibly on a submodule other than 'foo', wouldn't the natural thing to do would be to run "git pull" at the top-level, maybe with "--recursive" to update the top-level and all the submodules to start the day. Now, since somebody created the top-level commit you have just pulled and checked out, other people may have worked on submodule 'foo' [*1*]. What should happen on "git submodule update foo"? It would notice that the submodule 'foo' is set to float, and would check out the tip of the branch 'bar', not the commit recorded in the top-level superproject, in the working tree for 'foo', no? What should appear in "git diff"? The working tree taken as a whole is different from what the superproject's commit describes (which is the state the person who created the superproject wanted to record) even though this user does not have anything to do with the change at 'foo' from the recorded commit to the current tip of 'bar'. What would his description for the reason why the branch was updated? I think I would agree that "git diff" should not hide such changes (after all, when this user records his change to the overall project in the top-level supermodule, he will be recording the state with the commit at the tip of 'bar' checked out in the working tree of the submodule 'foo'), but I am not sure if the user can say anything sensible, other than "tip of 'bar' branch in submodule 'foo' was changed by others", in the resulting commit. [Footnote] *1* This may look like a non-issue if you assume that the person who updates the 'bar' branch of submodule 'foo' always updates the gitlink in the superproject's commit to point at that updated commit, but that assumption is flawed; the submodule project is a project on its own and can be worked on without what other projects bind it as their submodules. -- 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