Am 05.01.2010 10:46, schrieb Johannes Schindelin: > But I have a use case here where the shared content is _not_ a library > that can live in a subdirectory naturally. Yes, we had to reorganize a major part of one project too. Heiko could tell more about that. >> Having read up about svn externals in the meantime, what about something >> like this: >> - Add a command like "git submodule forward" (as update is already in >> use) that takes an optional -b <branchname>. It does a fetch in the >> submodule, then tries to fast forward (or rebase) to master or the >> branch given and stages this commit in the superproject. This should >> be the equivalent to doing an "svn update" in a repo with externals. >> Or am i missing something? > > Yes. It is not the decision of the fetcher, but of the guy who adds the > submodule to decide what it is. > >> - We could also add an option to "git submodule add" to specify the >> default branch name for forward. > > That's an obvious precondition for proper always-tip-submodules. But > Git's core data structure, the index, does not allow for it. _That_ is > the difficulty, not what the user interface would look like. I have never experienced (and never had the need for) such an always-tip scenario and therefore still seem to have difficulties to grok it. I assume you always want to have the newest tip at /checkout/ time, not at /commit/ time? Then my proposal would really not help you. > I start to wonder whether the insistence that .gitmodules' settings must > be overrideable makes any sense in practice. I know of none, maybe someone else can speak up here? (And even if it is overrideable, do the settings necessarily have to be copied into .git/config when they aren't even overridden?) -- 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