On 7/28/08, Pierre Habouzit <madcoder@xxxxxxxxxx> wrote: > On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote: > > That too indeed (the "easier to clone" bit). OTOH, I don't like the > > .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout > > inside of it. With what I propose, you find objects for all your > > super/sub-modules in the usual store, which eases many things. > > Especially, I believe that when you replace a subdirectory of a project > > with a submodule, git-blame could benefit quite a lot from this to be > > able to glue history back through the submodule limits, without having > > to refactor a _lot_ of code: it would merely have to dereference so > > called "gitlinks" to the commit then tree, hence twice, and just do its > > usual work, with your proposal, we still rely on having to recurse in > > subdirectories which requires more boilerplate code. > > And of _course_ this is also true for git-log, which is like 10x as > important for me (like I don't remember if I used git-blame this year, > whereas I used git-log in the last 10 minutes ;p) I don't think you're going to get away with *not* having a separate .git directory for each submodule. You'll just plain lose almost all the features of submodules if you try to do that. Most importantly in my case, my submodules (libraries shared between apps) have a very different branching structure than my supermodules. It wouldn't be particularly meaningful to force them to use the same branch names. Further, if you don't have a separate .git directory for each submodule, you can't *switch* branches on the submodule independently of the supermodule in any obvious way. This is also useful; I might want to test updating to the latest master of my submodule, see if it still works with my supermodule, and if so, commit the new gitlink in the supermodule. This is a very common workflow for me. On the other hand, your thought about combining the "git log" messages is quite interesting. That *is* something I'd benefit from, along with being able to git-bisect across submodules. If I'm in the supermodule, I want to see *all* the commits that might have changed in my application, not just the ones in the supermodule itself. I suspect this isn't simple at all to implement, however, as you'd have to look inside the file tree of a given commit in order to find whether any submodule links have changed in that commit. It's unfortunate that submodules involve a commit->tree->commit link structure. > One irritating problem with submodules, is > that when someone else commited, and that you git submodule update, > you're on a detached head. Absolutely horrible. I think that roughly everyone agrees with the above statement by now. It would also be trivial to fix it, if only we knew what "fix" means. So far, I haven't seen any good suggestions for what branch name to use automatically in a submodule, and believe me, I've been looking for one :) Have fun, Avery -- 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
