On Thu, 2008-05-01 at 15:55 -0400, Avery Pennarun wrote: > > o Branching "crawler" means branching "os-lib" > > o You can send a patch that contains changes both to "crawler" and "os-lib" > > and get it applied in a resonable way as ONE modification (and git-am > > would do the right thing) > > o Merging branch a and branch b in "crawler" also merges the matching > > branches a and b in "os-lib". > > o Pushing the supermodule also pushes the submodules > > The above would fit fine into my workflow, although it might be more > fancy than I really need. Personally, I don't mind thinking of my > submodules as separate projects (ie. I should expect to commit, > branch, merge, and push separately). But if the above features > existed I would adjust my working style to use them, just for the > added day-to-day convenience factor. > > Doing things like a single patch against one repo is a bit messy, > because (presumably) you'd have the same commit message in both repos, > which wouldn't really make sense. May be my brain is saturated with "partial cloning" but somehow the following looks like an interesting twist on a decentralized SCM: imagine that the picture given by Finn Arne Gangstad weren't static. IOW, os-lib wasn't really a separate component to begin with but was first developed as part of a "crawler" and only when the other team started to implement "indexer" there was a need for os-lib to be shared between two independent projects. Is there any nice way to express such a dynamic history sharing, short of truly refactoring os-lib into a separate Git repository and treating it either as a submodule or a subtree-merge? Thanks, Roman. -- 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
