Junio C Hamano wrote: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: >>> 3) never need to be aware of repo boundaries or manipulate sub-repo >> >> I think that this requirement is the hardest for any solution I know >> of or can imagine, as you hit these boundaries sooner or later either >> when you want to commit, push and/or when you have to resolve merge >> conflicts. > > Just a quick sanity check. When this "requirement" makes sense, does the > whole thing need to be a superproject with bunch of submodules, and why? In this example: because the submodule represents individual questions that are used by multiple exams. Another instance of the same (slightly uncomfortable :)) practice: suppose a certain chapter is part of multiple works I have published --- maybe in an article and a larger book. When working on the book: - I do not want to make changes to that chapter and forget to commit them. - After making changes to many chapters, I do not want the fuss of going from chapter to chapter and commiting them one by one. - I certainly do not want to publish a version of the book that "includes" versions of the chapters as dead links, so to speak. That is, when I publish the current version of the book, I want to publish the current version of all chapters, too. - When starting work on the book again after long absence, I would like to be able to see and have the chance to adopt changes to chapters made as part of this book and as part of others. If I understand correctly. -- 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