Jon Seymour <jon.seymour@xxxxxxxxx> writes: >> But once people realize that there is no single canonical authoritative >> repository whose branch heads point at the same commits for everybody in a >> distributed environment, the line of thought to touch gitlink entries gets >> retracted or discarded as a misguided idea. >> > > I understand the point about there being no canonical authority, > particularly in a truly distributed environment - any use of branches > would have to imply that users followed some convention when > publishing the entire set. > > On the other hand, there is actually precedent for use of convention > like that in the submodule facility - the use of relative paths to > describe the relative locations of submodule repos only really works > if everyone who publishes the supermodule uses the filesystem > structure for the directories containing the super- and sub-module > repos. That's not exactly what I meant. If the superproject commit didn't record the exact commit for each submodule, and only said "the tip of branch X" (presumably "as of this writing"), then there is no way to reliably reproduce the build product given the superproject commit alone. >> I however don't think it would hurt to enrich .gitmodules with not just >> the repository information but with branch information to help clones >> decide which commit (other than what is recorded in the tree of the >> superproject's commit) on the named remote tracking branch to try out with >> the superproject's commit. > > I can see that this could work. Presumably git submodule sync would be > modified in this case to help switch branches. There are two ways to use submodules. As I said already, the superproject commit records exact commit for each submodule by design, to ensure that the exact state including submodules can be reproduced. You manage submodules as separate projects, and the top level superproject commit picks a _good_ commit suitable for the purpose of the superproject, not just a random one that happens to be at the tip for a given day, to use from the submodule. But it is not implausible for the top level maintainer of thesuperproject of a project not to even care about what s/he is shipping exactly, and instead wish to describe "under this top level directory, check out these projects my colleagues have as subdirectories" and nothing else. In such a case, the exact commit for each submodule recorded in the superproject still can be used to reproduce the exact state if the top level maintainer cared, but you can instead _choose to ignore_ that information and check out the random commit that happen to be at the tip of the named branch. It could appear that such a use pattern is abusing the submodule support merely to implement a glorified ftp, but in a project that is run that way, everybody understands and agrees that the commit object recorded in the superproject is meaningless, so there is no harm done. > I guess there is no reason why I cannot prototype a facility of this > kind with a local helper script. If I it ends up being useful, I'll > consider posting a patch. Yes, that's the spirit ;-) -- 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