From: Avery Pennarun Date: Fri, 16 May 2008 14:12:16 GMT Subject: Re: Why do git submodules require manual checkouts and commits? Message-ID: <32541b130805160712m24f24c6aw59b54a0f0ace6269@mail.gmail.com> In-Reply-To: On 5/16/08, Johannes Schindelin wrote: > 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