Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk

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.

quoted

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.

quoted

- 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?)