On 5/16/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
quoted text
>  On Fri, 16 May 2008, Avery Pennarun wrote:
>  > So I think it would be very bad if the supermodule automatically
>  > updated to the latest version of the submodule whenever you commit in
>  > the submodule.  *However*, the other way around might be fine: if you
>  > commit in the supermodule, maybe it should commit in the submodule at
>  > the same time and link to that specific commit.  I'm pretty sure that
>  > idea doesn't have any *fundamental* flaws, it's just got a lot of
>  > really tricky details that need to be worked out.
>
> Just the fundamental flaw that you might _not_ want to commit that, just
>  as you can have a dirty Makefile _forever_.

I consider that one of the annoying details rather than a fundamental
flaw.  I agree that it's hard to solve though.

Think of it this way: I can commit, or not commit, my dirty Makefile
at the same time as everything else (in a single project) with a
single "git commit" line, depending on what I want to do.  Things like
"git commit -a" and "git add -u" speed up the common case where I just
want to commit everything.  But with submodules, that common case
looks more like this:

   cd sub
   git checkout -b manual_branchname_because_there_was_no_default
   git commit -a
   git push etc.
   cd ..
   git commit -a
   git push etc.

That's *really* tedious, and the number of commands multiplies when
you have more than one submodule going at once.

I think git's submodules are awesome because they *don't* have
fundamental flaws.  They just need an (optional) more automated
workflow for the common case.  And I'll be sure to propose one when I
figure out what my common case actually is :)

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html