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 *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html