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

> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
> > Am 04.01.2010 23:29, schrieb Johannes Schindelin:
> > ...
> >> - among other use cases, submodules are recommended for sharing 
> >>   content between two different repositories. But it is part of the 
> >>   design that it is _very_ easy to forget to commit, or push the 
> >>   changes in the submodule that are required for the integrity of the 
> >>   superproject.
> >
> > Definitely (and if i got that right, svn externals have the same 
> > problem).
> >
> > What about checking for every submodule before a push in the 
> > superproject that its HEAD is on a remote branch? I don't think we can 
> > provide full safety here, but we could handle the 99% case of a 
> > forgotten push in the submodule. This could even be done with a rather 
> > simple hook (if we had a pre-push hook that is :-).
> 
> You don't need "pre-push" hook, if the eventual goal is to integrate this
> into "git push" proper; it can notice submodule directories, descending
> into them, check if the remote lacks the necessary commit and invoke "git
> push" via run_command() interface as needed.

> >> - related are the use cases where it is desired not to have a fixed 
> >>   submodule tip committed to the superproject, but always to update 
> >>   to the current, say, master (like Subversion's externals).  This 
> >>   use case has been wished away by the people who implemented 
> >>   submodules in Git.  But reality has this nasty habit of ignoring 
> >>   your wishes, does it not?
> >
> > 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?  (And we could avoid the detached HEAD in 
> >   the fast forward case by really checking out the branch in the 
> >   submodule)
> > - We could also add an option to "git submodule add" to specify the 
> >   default branch name for forward.
> 
> Instead of recording a specific submodule commit in the superproject, we
> could record a branch name (this would need a separate "gitlink" type of
> object we toyed around during the early days of submodule design) to say
> "the tip of the branch".

> But there is a difference between a distributed system and a centralized 
> one like Subversion.  When you say "tip of the branch", you have to say 
> "which repository".  If your position is that _any_ repository will do 
> as long as the commit is at the tip of the named branch, that is like 
> saying you don't care what commit it really is, as you are free to muck 
> with branch heads in your copy of submodule repository, by adding 
> commits, or resetting new ones away.  For that matter, your 'master' 
> branch in the submodule repository may not build-on/fork-from the 
> 'master' branch in the upstream of it, so even "tip of the branch by 
> _this name_" is still fuzzy.
> 
> I am not saying "any commit will do" is necessarily a bad position to 
> take.  But people who claim they want to say "this branch" need to 
> realize what they are really saying: whatever you record in the 
> superproject commit is immaterial.  In other words, "this superproject 
> will work no matter which version of submodule is checked out at its 
> location".
> 
> Thatv actually is a very valid thing to say in some situations (Dscho
> mentioned different versions of artwork checked out as a submodule in a
> developer's superproject to build an app).  Interestingly enough, some
> people seem to think that we place too much importance on not having to
> check out submodules, but it indeed is a very natural extention of "any
> commit will do".  If the configuration you chose for your build does not
> depend on any files from there, it will truly be "any commit will do",
> including "nothing checked out there is just fine".