Am 13.09.2011 00:49, schrieb Jeff King: > So with a set of changes like: > > [assume submodule at commit A, superproject at commit B] > > 1. Make commit C in submodule repo. > > 2. Make commit D in superproject repo. > > 3. Make commit E in submodule repo. > > 4. Make commit F in superproject repo. > > what does it buy us to find out that the submodule changed from "A" to > "C"? We can't actually fetch it. We can only fetch the tips of the > submodule and hope that they include everything we wanted (i.e., both C > and E; which might not be the case of E rewound and is not a descendant > of C). Yes. But working with submodules in my experience only then works well when you never drop a submodule commit recorded in any superproject. At my dayjob we have the convention: You may only record commits that are on the submodule's master - or another never to be rewound integration branch - in the superproject. That gives us all needed commits in a simple fetch. > So since we must accept that we can't necessarily get every intermediate > step, I wonder if we are simply better off diffing the "before" and > "after" state of a particular ref, rather than traversing. It's way > cheaper, and is just as likely to give us the same information (i.e., > which submodule paths had changed commits). The real world use case I have for that is that when a bug introduced by a new submodule commit is detected later on, the superproject's fix records an older submodule commit to remove the problematic change from the superproject. But the submodule's branch isn't rewound (as that is most probably master) but a fix is applied on top of it. Then that one gets tested and - if it was found ok - recorded in the superproject. Changes like this could be overlooked if you only compare "before" and "after" instead of traversing, leading to not fetching a submodule which does have new commits that are used in the newly fetched superproject's commits. I'd like to have on-demand fetch keep the correct solution of traversing unless we have good reasons against it, especially as teaching checkout & friends to recursively update submodules too depends on all needed commits being present. -- 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