Re: [RFC] Submodules in GIT

[Daniel Barkalow <barkalow@iabervon.org>]

On Sat, 2 Dec 2006, Linus Torvalds wrote:

> So that's where I come from. And maybe I'm totally wrong. I'd like to hear 
> what people who actually _use_ submodules think.

I think you'd rather hear from people who _would_ use submodules; I've 
worked on a number of projects that would have benefitted from that 
general functionality, but nobody trusted the implementation enough to 
actually use it.

At my work, we're doing a bunch of stuff with microcontrollers. We've got 
about a dozen different boards with microcontrollers, and each of them has 
different firmware. We also have a bunch of code that can go on any of the 
boards.

The way things are organized currently is that each board has its own 
project, and there's a "common-micro" project with the common code. This 
sort of works, but it means that when you change things in common-micro, 
you never know what effect this will have on boards other than the one 
you're actually working on. What I'd like to have is that each project has 
a "common-micro" subdirectory, and changes to each of these can be merged 
into each other, but that doesn't happen automaticly, and each board's 
revisions include the common-micro revision they were created with.

A few notes: 

I'd never work on common-micro in isolation. Nothing in there even 
compiles by itself, because the compiler needs to know the target 
microcontroller type, which depends on the board it's for. It only makes 
sense to prepare a new revision of "common-micro" in the context of some 
particular board, at least if you want to test it at all.

I'd sometimes want to include temporary hacks in the common-micro for a 
particular board, when things are late and I need to change some library 
behavior in a way that I know works for the board I'm working on, but I 
don't have time to think about all of the other boards (each of which is 
special in some way).

I'd often make some change that I know improves the cleanliness of 
common-micro, but which requires changes to every board to compensate. I 
don't want to make all of the changes at once; I'll update each board 
appropriately the next time I work on it. But, of course, until I update 
each board, that board needs to keep using the version of common-micro 
without the changes.

I don't want to have repository states where stuff doesn't work, which 
means I can't do it as one big tree; I need to be able to make a commit 
with board1 and a common-micro change without having a version of board2 
that would use the changed common-micro, because I haven't come up with a 
board2 version that works with it yet.

	-Daniel