Glad you could make some progress. I'll reply on your discussions/questions:

> In, would 
> you say that 
> his "upstream" branch has some arbitrary content? 

I'd say it looks like he's forking the original wordpress distributable. 
His repository *is* wordpress (or a wordpress derivative).

> Personally, for these reasons, I find it very appealing. 

Sure, it's not directly wrong either. The nice thing about Git is that 
you're free to use it as you see fit.

> (Especially as our external libraries are all lightweight and considered 
> closely related 
> to the main project.) 
> Submodules, in contrast, are described as problematic in each book that 
> I've read so far 
> (and there are many internet resources in the same spirit), and seem 
> mostly suited, as 
> you say, for things that don't belong there. 

Yes, submodules are a bit outside the normal Git workflow, and aren't what 
most people expect when they want to use them. I've seen a lot of people 
(including myself) started doing submodules as a replacement for svn 
externals <>, only to 
realize that submodules are kind of version-sticky, not floating to the 
latest commit like svn-externals do. Trying to force submodules into this 
and other unintended usages have lead a lot of people to think that they 
are awkward and hard to use.

I think this page does a fine job of explaining the case for submodules:

> As I mentioned in my previous post 
> (, I 
> can see how 
> submodules are a natural fit for a library that is huge in size, has an 
> incompatible 
> license or otherwise restricted distribution terms compared to the core 
> project, and/or 
> that we don't ever intend to modify. 
> I'm happy to stand corrected, but at the moment, the 
> approach 
> looks a 
> lot simpler and more attractive than submodules to me.

No one can correct you in this sense. What works best for you is the 
correct thing for you.

> > You then clone each of the vendor repositories, 
> Why "each"? 
I could as well clone "vendor" as a whole, couldn't I?  

One repo should have one versioning scheme. Think about tagging. You want 
to identify versions of lua "1.0", "1.1", and so on. If you keep a lot of 
products in one vendor repo, it will be filled with tags of different 
versioning schemes like "lua-1.0, zlib-5.3" and so on. This works as well, 
of course, but it doesn't feel "clean". Separation of concerns and all that.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to