On Wed, 31 Oct 2007, Johannes Schindelin wrote: > > Seriously, your proposal does not make any sense. If you have to set up a > hook to get the _sane_ behaviour, something is really wrong. So I do not > really understand why you brought up this idea here and now. Well, I think this does kind of have some commonality with another issue that has come up before: git clone only clones the really core repository data. That's generally a big feature, and I think it's absolutely the correct thing to do. But I can also see that sometimes, you might want to clone more than the actual repository, and get things like SVN metadata, branch reflogs, various hooks and all the config options too. Of course, in practice, at least right now, the right thing to do for that is to just do a recursive filesystem copy and then a "git status", but I think the background here is that some people simply do end up wanting to transfer more infrastructure than just the actual repository data. One thing to note: one reason for *not* allowing that is that incremental upgrades of non-repo data is obviously not possible. You might be able to *clone* a repo with config info and other metadata (if nothing else, then by just doing that raw filesystem copy), but you will never ever be able to _fetch_ the updates, because they aren't part of the core repository, and aren't versioned. So I think I can understand why some people would want to do things like this, but I do think it's broken. Yes, you can make the grafts file (or the config file) be part of the repo, and even just add a symlink to your .git/ directory, but it's simply not a very good model. So I think it always does end up breaking (other people might rebase, and break your grafts, or just not want them in the first place, or they don't care about the same things, and mess up "your" configuration etc etc). So the git repo layout is designed to have the minimally required shared state, and not anything else. Linus - 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
