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


> In http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/, 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 <http://svnbook.red-bean.com/en/1.0/ch07s03.html>, 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: 
http://git-scm.com/book/ch6-6.html
 

> As I mentioned in my previous post 
> (http://article.gmane.org/gmane.comp.version-control.git.user/3493), 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 happygiraffe.net 
> 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 
https://groups.google.com/d/msg/git-users/-/hwTxNO9QJsAJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to